[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


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]