Carsten Neumann wrote:
> Hi,
>
> I've redone the way options are handled by the {Image,Scene}FileHandler
> and propose attached patch. The main changes are:
I see why one would want to avoid a single string containg all options,
but why lose having a string representation of the value?
Why not std::string as value, then convert in the reader class? (using
boost::lexical_cast in getOptionAs). It feel like the current scheme
makes it difficult to pass options in as strings from a
script/cmdline/whatnot, or did I miss something?
Minor details:
It should be specified that IOFileTypeBase::getOptionAs(std::string
const &name) throws boost::bad_any_cast on failure, so the application
can catch that that. (Or that behaviour is undefined..)
If getOptionAs took the output value as a non-const ref, you wouldn't
need to specify the template type. Less repetition of types => safer
code. (IMHO).
Also, why write 'std::string const &', and not 'const std::string &', as
it's usually done?
Otherwise, it looks pretty neat. :)
Cheers,
/Marcus
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
