[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu3dkit-discuss] Re: [Gnu3dkit-dev] Strings and parameter lists
From: |
Gerard Iglesias |
Subject: |
[Gnu3dkit-discuss] Re: [Gnu3dkit-dev] Strings and parameter lists |
Date: |
Sun, 9 Feb 2003 22:55:24 +0100 |
Hi,
Some points :
The question here is do we want to be able to read, write or read and
write RIB files. If we ie. only have to write RIBs then we could ie.
provide a special action implementation which generates a RIB from the
scene graph.
About RIB, it would be very nice to have read and write RIB, obviously
the writing is the easiest. I am working on it now, not too fast but I
am working on it :) I didn't find nothing open source to read rib
files. I am hesitating to write my own parser or use lex and yacc (well
flex and bison). In fact this capacity would a big plus for our 3DKit...
Wrt the drawing API I think that if we can come up with an API
covering all of the RM primitives then we cover already a good portion
of what we need.
Exactly, if we can parse a rib file then we have a lot of stuff :)
working on the renderer API I encounter some problem/issues with
strinsgs. In RenderMan everything is handled via C strings (tokens),
back in the NEXTSTEP days this would have been used directly 'as is'.
Now since OpenStep the use of NSString is recommended and C strings
are more or less banned from the API although this imposes some
overhead.
But using stringWithCString to build the c string use optimized
NSString backend, I believe.
My problem now is how to map the RenderMan C interface to a proper
G3DRenderer Objective-C interface: should we use plain C strings or
NSStrings?
We have to be consistent, and not optimize the stuff too early. The
ObjC API has to use NSString, we will see if this is a issue.
Moreover RenderMan uses parameter lists in many places which could be
handled either via variable argument lists or NSDictionary objects.
I'd prefer to use the latter (from an OO perspective), but I'd like to
hear your opinion on that as well before I go on here.
I have the same opinion as you, variable list of arguments is hard to
debug.
But NSDictionary is costly :(
I vote for the NSDictionary for now.
So the main question here is probably whether we want to design a pure
Objective-C API or mix it with a C interface. Again, I'd choose the
Objective-C approach, but...
I think that we have to make ObjC first, because if speed become a real
issue I think that it will be better to give a complete equivalent C
interface, a little bit as CoreFoundation/Foundation
Best regards
Gerard
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gnu3dkit-discuss] Re: [Gnu3dkit-dev] Strings and parameter lists,
Gerard Iglesias <=