Hi,
Gerrit Voss wrote:
> On Fri, 2008-05-09 at 10:10 -0500, Carsten Neumann wrote:
>> I've redone the way options are handled by the {Image,Scene}FileHandler
>> and propose attached patch. The main changes are:
>>
>> - an option is a name (std::string) and a value (boost::any)
>> - an option set is a map from name (std::string) to option
>> - {Image,Scene}FileType derive from a common base class (IOFileTypeBase)
>> which holds a stack of option sets that always contains at least one
>> element (the current option set).
>> - IOFileTypeBase has some convenience access functions to retrieve
>> options and their values.
>>
>> Most loaders have an internal representation for options as well (mainly
>> osb, wrl) which has not been touched except for adjusting the functions
>> that translate the option set into the internal rep.
>
>
> that does not look right.
>
> boost::any const &
> IOFileTypeBase::getOption(std::string const &name) const
> {
> OptionSet::const_iterator oIt = _optStack.top().find(name);
>
> oIt->second;
> }
why? because it does not check for oIt == _optStack.top().end() ? This
as well as the corresponding getOptionAs<> are intended for when it is
known that the option is present - the doxy comment has a warning about
this.
Anyway, please see below.
> Another one, why do we need 3 different getOption{As} functions in
> IOFileTypeBase ?
I like to offer choices ;) . But in this case it is probably
cleaner/less confusing to have just one interface, so I'll just get rid
of those functions that return the value and only keep those that take a
non-const reference to return the value in.
> Otherwise I'm fine with it.
Marcus seems to prefer to have options basically as a pair of strings. I
generally prefer storing values as their correct type and not as a
string, but in this case I have no strong opinion on the issue. Anyone
else having a feeling on what might be more convenient for writing apps?
Thanks,
Carsten
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
