Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-20 Thread Robert Osfield
Hi Vincent, On Wed, May 20, 2009 at 7:57 AM, Vincent Bourdier vincent.bourd...@gmail.com wrote: If you think of any solution, I would be very interested to hear it. It looks like you there are two viable solutions. 1) Don't use Windows :-) 2) Move the implementation of your singleton into a

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-20 Thread Vincent Bourdier
Hi Robert, 2009/5/20 Robert Osfield robert.osfi...@gmail.com Hi Vincent, On Wed, May 20, 2009 at 7:57 AM, Vincent Bourdier vincent.bourd...@gmail.com wrote: If you think of any solution, I would be very interested to hear it. It looks like you there are two viable solutions. 1) Don't

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-19 Thread Vincent Bourdier
Hi all, A little new question about a c++ implementation of registry : The static method instance() return a new registry each time, so each call have a new instance, so how can the registry's class plugin list can be good ? any call to registry::instance()-addReaderWriter() add the the

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-19 Thread Robert Osfield
HI Vincent, Go have a look at the source code, it contains the single static instance of the Registry, so the method only ever returns a single Registry. It would be worth your reading up about static variables in C/C++ so you can understand how this stuff works, it really beyond the scope of

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-19 Thread Vincent Bourdier
Hi Robert, The this I don't understand, is that I copy the code for my own registry, with exactly the same static implementation, but I get a new instance each time I call the instance(). The constructor is called and the adress changes... This is a part of the code : Registry*

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-19 Thread Robert Osfield
Hi Vincent, It's odd that your report that your get different instances each time. This suggest you've not implemeneted something correctly. Most of the OSG wouldn't work if there wasn't a single Registry so it does work on the OSG side. As a general note I have moved from using the

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-19 Thread Vincent Bourdier
Hi Robert, I think I get it : I seems to be due to the osgDB::DynamicLibrary instance I use, which ref_ptr unref when leaving the load code, so the destructor of the RegisterReaderWriterProxy (my equivalent) was called, and it seems to be sufficient to force a new call to the Registry

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-19 Thread Robert Osfield
On Tue, May 19, 2009 at 2:24 PM, Vincent Bourdier vincent.bourd...@gmail.com wrote: Hi Robert, I think I get it : I seems to be due to the osgDB::DynamicLibrary instance I use, which ref_ptr unref when leaving the load code, so the destructor of the RegisterReaderWriterProxy (my equivalent)

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-19 Thread Vincent Bourdier
Hi Robert, I get more info : the singleton is not destroyed, but is called from the lib I did and from the exe itself. When the lib call the singleton, it works good. when the exe call the singleton, It does a new call to constructor ... Any idea about how to solve that problem ? Thanks.

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-19 Thread J.P. Delport
Hi Vincent, are you adding the export thingymajiggies to the singleton in your lib for Windows? Getting singletons to work across DLL's in Windows is a pain. We've had the same issues on Windows where a singleton was not exactly a singleton. We were using the Loki::SingletonHolder and got it

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-19 Thread Robert Osfield
Hi Vincent, Looking at J.P. follow up email it does sound like it could be windows specific issue. Are you using windows? Is you singleton implemented in a header? If so the just have the declaration in the header, and keep the implementation entirely within the .cpp to ensure that the

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-15 Thread Vincent Bourdier
Hi all, thinking for hours and digging my problem, I have a choice to make, but I think some external advices could be useful : I you need to load dynamically some DLL (as osg plugins) but theses DLL have no similar I/O (so make each one inherit from a base class have no sense), how will you do

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-15 Thread Vincent Bourdier
Hi Art, I need to make these lib (dll/so) for linux and window at least, so I need common behavior. I'm thinking a mix of the inheriting class and the osg plugin registry behavior with the template static register method ... (note so understandable I think) that is to say, may be a mix of all

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-14 Thread Vincent Bourdier
Hi all, I've just spent some hours running into the osgDB code, and some littles things are more clear but there is the big question I cannot answer : The method DynamicLibrary::PROC_ADDRESS DynamicLibrary::getProcAddress(const std::string procName) is for me the only one which the loader must

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-14 Thread Art Tevs
Hi Vincent, osgDB Plugins register them self to the db registry. If you take a look into every plugin, there is some kind of proxy global object. The constructor of this get initiated as soon as library is loaded, and in the constructor the plugin register himself to the osgDB. Hence no magic

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-14 Thread Ulrich Hertlein
Hi Vincent, On 14/5/09 10:44 AM, Vincent Bourdier wrote: I've just spent some hours running into the osgDB code, and some littles things are more clear but there is the big question I cannot answer : The method DynamicLibrary::PROC_ADDRESS DynamicLibrary::getProcAddress(const std::string

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-14 Thread Vincent Bourdier
Hi Ulrich, Art , Thanks for the answers. So if I understand well, when the dll is loaded by dynamic_library, the REGISTER_OSGPLUGIN(...) create a static function, which is stacked in the registry, just because of the load. This is just native C++ behaviour, or do I miss some things... ? I just

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-14 Thread Ulrich Hertlein
Hi Vincent, On 14/5/09 11:53 AM, Vincent Bourdier wrote: So if I understand well, when the dll is loaded by dynamic_library, the REGISTER_OSGPLUGIN(...) create a static function, which is stacked in the registry, just because of the load. This is just native C++ behaviour, or do I miss some

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-14 Thread Vincent Bourdier
Okay, so I implement a myClass in the core, and I declare a static myClass mycalss in my DLL. so, I can call with the static implementation, the methods I want in the DLL from my core. A last point I would like to understand : in each plugin, there is the magic : REGISTER_OSGPLUGIN(...)

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-14 Thread Ulrich Hertlein
On 14/5/09 12:13 PM, Vincent Bourdier wrote: #define REGISTER_OSGPLUGIN(ext, classname) \ extern C void osgdb_##ext(void) {} \ static osgDB::RegisterReaderWriterProxyclassname g_proxy_##classname; So the static member is for communication, but the osgdb_##ext is for what ? I didn't

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-14 Thread Art Tevs
Hi Vincent, Vincent.B wrote: Okay, so I implement a myClass in the core, and I declare a static myClass mycalss in my DLL. so, I can call with the static implementation, the methods I want in the DLL from my core. Not really, you implement a static/global variable, which will then

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-14 Thread Vincent Bourdier
Hi Art, This is not the same thing ? Case 1 : static variable in the dll, calling the register - add on declaration. when the dll is loaded, the static member is initialized, so the register call the dll variable constructor and add it on its available dll stack (see RegisterReaderWriterProxy

[osg-users] Understanding OSG : plugins runtime loading question

2009-05-13 Thread Vincent Bourdier
Hi all, I'm currently making a dynamic lib for my application, and so I use the osgDB::DynamicLibrary class to load the lib and find the Proc_adress but, there are some points I would like to understand more : 1. The osgDB::DynamicLibrary::PROC_ADDRESS is just a void* so to use the adress as a

Re: [osg-users] Understanding OSG : plugins runtime loading question

2009-05-13 Thread Vincent Bourdier
Hi Ismail, Not sure to understand all you explained, I didn't find a simple answer to my questions. I know that the getProcAdress return a void*, but I was asking about the osg getProcAdress, and if is there any way different than the cast to get the function usable ... and to know how this is