On Thu, Nov 6, 2008 at 3:51 PM, David Spilling <[EMAIL PROTECTED]> wrote:
> Heh. I wondered if that was the reason that previous plugin writers had made
> such efforts to avoid it (although the OpenFlight loader seems to use it -
> is that a different case)?
If a plugin sets local variables during read/write then it has to use
a mutex to serialize all access to it. The OpenFlight plugin does
this.
If you can avoid it then it's best not to force this serialization on a plugin.
As for examples of doing it the right way, I can't think of one
particular one tight now. It's a simple as
struct MyStruct {
int opt1;
int op2;
};
void doSomething(const MyStruct&)
As for osgDB::ReaderWriter::Options, you can subclass this, at it's
one of the design capabilities of this class, but the restriction is
that you have to publish this subclass so that the app can populate
it, and the subclass can read from it.
In terms of replacements for the OptionsString - there isn't a general
purpose one right now. One needs to bare in mind this code was
written in the very early days of the OSG and was written to the needs
back then, and has the class has evolved over the years with new
capabilities being added, but it hasn't required wholesale rewrite.
I'm certainly open to see better option passing capabilities. Added a
std::map<std::string, std::string> is something I've considered as a
successor to the OptionString. Note we already have a
std::map<std::string, void*> for passing data in and out of plugins,
but in this case we don't want to pass in objects, just settings.
Robert.
>> but the way
>> to tackle is to create an options object that packs this variables
>> together and then you just pass a reference to to object
>
> Can you point me at an example in the plugins?
>
> While I'm here, I didn't like the way that options had to be passed as
> strings - it seemed ugly. Is there a better way of defining this - e.g. a
> plugin independent way, by extending osg::Options or something? I intend to
> apply the same sort of functionality to the 3DS loader, and it would be good
> to be consistent...
>
> David
>
>
> _______________________________________________
> osg-submissions mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>
>
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
