Thanks, Robert and Bryan, for tolerating this somewhat stupid post of mine without flaming me to a burnt crisp. :-) I has somehow misread the code and believed that there was only a "bool findString(string&)" method. Lesson learned: take a second look at the code before posting.
That all being said, your two posts did raise some interesting possibilities, such as alternates to using strings, a more efficient one-time parsing, etc. Not to mention providing an interface for querying on a key to retrieve a value. Hopefully I'll have a chance to investigate some of these possibilities in an upcoming project. -Paul > Hi Paul, > > osgDB::Options is just a base class, some one can extend it > and pass this subclasses into ReaderWriter if you want to > pass in extra information. > > There is also the OptionsString to help pass in options without the > need for subclasses. Its really down to the ReaderWriter parsing the > string to work out what the settings are, it typically is > treated as a boolean, but this is just down to the parsing, > its not an intrinsic restrictions. > > The use of key, value pairs is an interesting suggestion. > It'd certainly be simpler to parse than getting a string. I > don't know how you mean for the value to be represented, > another string? > > Robert. > > On 7/27/07, Paul Martz <[EMAIL PROTECTED]> wrote: > > > > > > Hi OSGers -- > > > > Currently, osgDB::Options is a string that either contains a given > > substring or it doesn't -- controlled parameters are > therefore essentially;y Booleans. > > As a result, the OpenFlight loader (for example) has five > Options to > > control units conversion: convertToFeet, convertToInches, > > convertToMeters, convertToMiles, and convertToNauticalMiles. Yuck. > > > > I'd like to enhance osgDB::Options to support key/value > pairs. Options > > in the string would become "<key>=<value>", and > osgDB::Options would > > have a new interface that would retrieve the value for a given key. > > Using the OpenFlight loader as an example again, If the > Options string > > contained "conversion=meters", then the loader could search > for the "conversion" key. > > and get back "meters" as a result. > > > > Seems like this change would add a lot of flexibility to > options. It > > would also allow a plugin to write an error message to > osg::notify if > > the key were correct but its corresponding value were > misspelled or out of range. > > > > Yet another advantage is that code would now be able to > send Options > > with numeric values to a plugin, something that's not possible with > > Options currently, as far as I know. This is actually the issue I'm > > facing at the moment, which is driving this change. > > > > Thoughts? > > > > Paul Martz > > Skew Matrix Software LLC > > http://www.skew-matrix.com > > 303 859 9466 > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. > > org > > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
