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

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
reader/Wirter in a new registry instance ... so how can it works correctly ?

Thanks for you help.

Regards,
   Vincent.

2009/5/15 Vincent Bourdier vincent.bourd...@gmail.com

 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 these way can
 bring me to a good solution ..

 Still here if you have suggestion or ideas

 Thanks every one, still good to have quality help here :-)

 Regards,
Vincent.

 2009/5/15 Art Tevs arti_t...@yahoo.de

 Hi Vincent,



 Vincent.B wrote:
  Hi all,
  If 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 ?
 
  I'm thinking in the calssical loadLibrary and getProcAdress for each
 one, ... but if you know or think in an other solution, I would be very
 interested to hear it.
 


 In windows world each dll can have an entry point. This is a C function,
 which will be called on dll loading. In unix world, I am not sure if there
 exists default entry point routines, I think yes, but I am not sure.

 cheers,
 art

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=12249#12249





 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

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 the OSG community to teach your this stuff.

Robert.

On Tue, May 19, 2009 at 11:54 AM, Vincent Bourdier
vincent.bourd...@gmail.com wrote:
 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
 reader/Wirter in a new registry instance ... so how can it works correctly ?

 Thanks for you help.

 Regards,
    Vincent.

 2009/5/15 Vincent Bourdier vincent.bourd...@gmail.com

 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 these way can
 bring me to a good solution ..

 Still here if you have suggestion or ideas

 Thanks every one, still good to have quality help here :-)

 Regards,
    Vincent.

 2009/5/15 Art Tevs arti_t...@yahoo.de

 Hi Vincent,



 Vincent.B wrote:
  Hi all,
  If 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 ?
 
  I'm thinking in the calssical loadLibrary and getProcAdress for each
  one, ... but if you know or think in an other solution, I would be very
  interested to hear it.
 


 In windows world each dll can have an entry point. This is a C function,
 which will be called on dll loading. In unix world, I am not sure if there
 exists default entry point routines, I think yes, but I am not sure.

 cheers,
 art

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=12249#12249





 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

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* Registry::instance(bool erase)
 {
 static Registry* s_registry = new Registry;

 if(erase)
 {
 s_registry-destruct();
 s_registry = NULL;
 }

 return s_registry;
 }


 class DLL_EXPORT Registry
 {

 public :

 static Registry* instance(bool erase = false);
 }


I know static variable is the same for each instance, but how can it be true
if the constructor is called each time ?

So i can't see the problem, considering this is the copy/paste of the osg
Registry code...

Thanks.

Regards,
   Vincent.

2009/5/19 Robert Osfield robert.osfi...@gmail.com

 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 the OSG community to teach your this stuff.

 Robert.

 On Tue, May 19, 2009 at 11:54 AM, Vincent Bourdier
 vincent.bourd...@gmail.com wrote:
  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
  reader/Wirter in a new registry instance ... so how can it works
 correctly ?
 
  Thanks for you help.
 
  Regards,
 Vincent.
 
  2009/5/15 Vincent Bourdier vincent.bourd...@gmail.com
 
  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 these way
 can
  bring me to a good solution ..
 
  Still here if you have suggestion or ideas
 
  Thanks every one, still good to have quality help here :-)
 
  Regards,
 Vincent.
 
  2009/5/15 Art Tevs arti_t...@yahoo.de
 
  Hi Vincent,
 
 
 
  Vincent.B wrote:
   Hi all,
   If 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 ?
  
   I'm thinking in the calssical loadLibrary and getProcAdress for each
   one, ... but if you know or think in an other solution, I would be
 very
   interested to hear it.
  
 
 
  In windows world each dll can have an entry point. This is a C
 function,
  which will be called on dll loading. In unix world, I am not sure if
 there
  exists default entry point routines, I think yes, but I am not sure.
 
  cheers,
  art
 
  --
  Read this topic online here:
  http://forum.openscenegraph.org/viewtopic.php?p=12249#12249
 
 
 
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

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
osgDB::Registry::instance approach to using something like:

osg::ref_ptrMySingletonClass MySingletonClass::instance()
{
 static osg::ref_ptrMySingletonClass s_mySingleton = new
MySingletonClass;
 return s_mySingleton;
}

This approach allows you to reset the singleton externally, so it's
not necessary to bool trick to get it to destruct.  With this little
tweak the implementation code becomes much cleaner.

Robert.


On Tue, May 19, 2009 at 12:25 PM, Vincent Bourdier
vincent.bourd...@gmail.com wrote:
 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* Registry::instance(bool erase)
 {
     static Registry* s_registry = new Registry;

     if(erase)
     {
         s_registry-destruct();
         s_registry = NULL;
     }

     return s_registry;
 }


 class DLL_EXPORT Registry
 {

 public :

     static Registry* instance(bool erase = false);
 }

 I know static variable is the same for each instance, but how can it be true
 if the constructor is called each time ?

 So i can't see the problem, considering this is the copy/paste of the osg
 Registry code...

 Thanks.

 Regards,
    Vincent.

 2009/5/19 Robert Osfield robert.osfi...@gmail.com

 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 the OSG community to teach your this stuff.

 Robert.

 On Tue, May 19, 2009 at 11:54 AM, Vincent Bourdier
 vincent.bourd...@gmail.com wrote:
  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
  reader/Wirter in a new registry instance ... so how can it works
  correctly ?
 
  Thanks for you help.
 
  Regards,
     Vincent.
 
  2009/5/15 Vincent Bourdier vincent.bourd...@gmail.com
 
  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 these way
  can
  bring me to a good solution ..
 
  Still here if you have suggestion or ideas
 
  Thanks every one, still good to have quality help here :-)
 
  Regards,
     Vincent.
 
  2009/5/15 Art Tevs arti_t...@yahoo.de
 
  Hi Vincent,
 
 
 
  Vincent.B wrote:
   Hi all,
   If 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 ?
  
   I'm thinking in the calssical loadLibrary and getProcAdress for each
   one, ... but if you know or think in an other solution, I would be
   very
   interested to hear it.
  
 
 
  In windows world each dll can have an entry point. This is a C
  function,
  which will be called on dll loading. In unix world, I am not sure if
  there
  exists default entry point routines, I think yes, but I am not sure.
 
  cheers,
  art
 
  --
  Read this topic online here:
  http://forum.openscenegraph.org/viewtopic.php?p=12249#12249
 
 
 
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

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 constructor.

Does it sounds right for you ?

Thanks.

Regards,
   Vincent.

2009/5/19 Robert Osfield robert.osfi...@gmail.com

 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
 osgDB::Registry::instance approach to using something like:

 osg::ref_ptrMySingletonClass MySingletonClass::instance()
 {
 static osg::ref_ptrMySingletonClass s_mySingleton = new
 MySingletonClass;
 return s_mySingleton;
 }

 This approach allows you to reset the singleton externally, so it's
 not necessary to bool trick to get it to destruct.  With this little
 tweak the implementation code becomes much cleaner.

 Robert.


 On Tue, May 19, 2009 at 12:25 PM, Vincent Bourdier
 vincent.bourd...@gmail.com wrote:
  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* Registry::instance(bool erase)
  {
  static Registry* s_registry = new Registry;
 
  if(erase)
  {
  s_registry-destruct();
  s_registry = NULL;
  }
 
  return s_registry;
  }
 
 
  class DLL_EXPORT Registry
  {
 
  public :
 
  static Registry* instance(bool erase = false);
  }
 
  I know static variable is the same for each instance, but how can it be
 true
  if the constructor is called each time ?
 
  So i can't see the problem, considering this is the copy/paste of the osg
  Registry code...
 
  Thanks.
 
  Regards,
 Vincent.
 
  2009/5/19 Robert Osfield robert.osfi...@gmail.com
 
  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 the OSG community to teach your this stuff.
 
  Robert.
 
  On Tue, May 19, 2009 at 11:54 AM, Vincent Bourdier
  vincent.bourd...@gmail.com wrote:
   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
   reader/Wirter in a new registry instance ... so how can it works
   correctly ?
  
   Thanks for you help.
  
   Regards,
  Vincent.
  
   2009/5/15 Vincent Bourdier vincent.bourd...@gmail.com
  
   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 these way
   can
   bring me to a good solution ..
  
   Still here if you have suggestion or ideas
  
   Thanks every one, still good to have quality help here :-)
  
   Regards,
  Vincent.
  
   2009/5/15 Art Tevs arti_t...@yahoo.de
  
   Hi Vincent,
  
  
  
   Vincent.B wrote:
Hi all,
If 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 ?
   
I'm thinking in the calssical loadLibrary and getProcAdress for
 each
one, ... but if you know or think in an other solution, I would be
very
interested to hear it.
   
  
  
   In windows world each dll can have an entry point. This is a C
   function,
   which will be called on dll loading. In unix world, I am not sure if
   there
   exists default entry point routines, I think yes, but I am not sure.
  
   cheers,
   art
  
   --
   Read this topic online here:
   http://forum.openscenegraph.org/viewtopic.php?p=12249#12249
  
  
  
  
  
   ___
   osg-users mailing list
   osg-users@lists.openscenegraph.org
  
  
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
  
  
  
   ___
   osg-users mailing list
   osg-users@lists.openscenegraph.org
  
  
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
  
  
  ___

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

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) was called, and it seems to be
 sufficient to force a new call to the Registry constructor.

 Does it sounds right for you ?

I can't comment on code I'm not party to.

As a general note one shouldn't be able to delete a internally
singleton used in my example without doing a instance()=0;  Just take
a ref_ptr to the return won't delete the object as the instance()
method keeps around a copy.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

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.

Regards,
   Vincent.

2009/5/19 Robert Osfield robert.osfi...@gmail.com

 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) was called, and it seems to be
  sufficient to force a new call to the Registry constructor.
 
  Does it sounds right for you ?

 I can't comment on code I'm not party to.

 As a general note one shouldn't be able to delete a internally
 singleton used in my example without doing a instance()=0;  Just take
 a ref_ptr to the return won't delete the object as the instance()
 method keeps around a copy.

 Robert.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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 to work
eventually. The details are more than I'd like to remember, but the
mailing list of the Loki libs had some good information.

http://sourceforge.net/mailarchive/forum.php?forum_name=loki-lib-general

See also here:
http://developer.vrjuggler.org/ticket/12

Vincent Bourdier wrote:

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.

Regards,
Vincent.

2009/5/19 Robert Osfield robert.osfi...@gmail.com
mailto:robert.osfi...@gmail.com

On Tue, May 19, 2009 at 2:24 PM, Vincent Bourdier
vincent.bourd...@gmail.com mailto: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) was called, and it
seems to be
sufficient to force a new call to the Registry constructor.

Does it sounds right for you ?

I can't comment on code I'm not party to.

As a general note one shouldn't be able to delete a internally
singleton used in my example without doing a instance()=0; Just take
a ref_ptr to the return won't delete the object as the instance()
method keeps around a copy.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

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
allocation happens single dll.

Robert.

On Tue, May 19, 2009 at 3:33 PM, Vincent Bourdier
vincent.bourd...@gmail.com wrote:
 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.

 Regards,
    Vincent.

 2009/5/19 Robert Osfield robert.osfi...@gmail.com

 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) was called, and it seems to be
  sufficient to force a new call to the Registry constructor.
 
  Does it sounds right for you ?

 I can't comment on code I'm not party to.

 As a general note one shouldn't be able to delete a internally
 singleton used in my example without doing a instance()=0;  Just take
 a ref_ptr to the return won't delete the object as the instance()
 method keeps around a copy.

 Robert.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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 ?

I'm thinking in the calssical loadLibrary and getProcAdress for each one,
... but if you know or think in an other solution, I would be very
interested to hear it.

Thanks.

Regards,
   Vincent

2009/5/14 Vincent Bourdier vincent.bourd...@gmail.com

 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 implementation)

 Case 2:
 in the dll constructor I call the registry-intance()::register(this) which
 does the same thing :stack the dll.

 Thanks,
Vincent.

 2009/5/14 Art Tevs arti_t...@yahoo.de

 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
 initialize your class. Here is a code example, which is a standard C++ and
 it will initialize your objects when loading the dll:

 Code:


 #include Registry

 class myClass
 {
   myClass()
   {
Registry::registerMe(this);
   }
 };

 static myClass g_myclass;




 This should be almost enough to achieve what you want.


 
  A last point I would like to understand :
 
  in each plugin, there is the magic :
  REGISTER_OSGPLUGIN(...)
 
  #define REGISTER_OSGPLUGIN(ext, classname)
  extern C void osgdb_##ext(void) {}
  static osgDB::RegisterReaderWriterProxyclassname
 g_proxy_##classname;
 

 So as you see REGISTER_OSGPLUGIN do exactly the same, what you can see
 from the code above.

 What is this extra function osgdb_ext(){} good for, I do not know. Maybe
 the idea was to implement some extra procedures inside of the dll, so that
 they could manually be called when loading the dll.

 cheers,
 art

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=12093#12093





 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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 these way can
bring me to a good solution ..

Still here if you have suggestion or ideas

Thanks every one, still good to have quality help here :-)

Regards,
   Vincent.

2009/5/15 Art Tevs arti_t...@yahoo.de

 Hi Vincent,



 Vincent.B wrote:
  Hi all,
  If 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 ?
 
  I'm thinking in the calssical loadLibrary and getProcAdress for each one,
 ... but if you know or think in an other solution, I would be very
 interested to hear it.
 


 In windows world each dll can have an entry point. This is a C function,
 which will be called on dll loading. In unix world, I am not sure if there
 exists default entry point routines, I think yes, but I am not sure.

 cheers,
 art

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=12249#12249





 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

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 use each time a plugin dll have
to be loaded.
But, there is no utilization, at no place ! So how can the osgDB core find
the good methods in the dLL without using this method ?
I'm not a c++ master, but for now, I feel lost in the c++ myst ...

Thanks.

Regards,
   Vincent.


2009/5/13 Vincent Bourdier vincent.bourd...@gmail.com

 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 used in the plugins because
 I didn't found any code using it.

 Thanks.

 Regards,
Vincent.

 2009/5/13 Ismail Pazarbasi pazarb...@gmail.com

 On Wed, May 13, 2009 at 9:47 AM, Vincent Bourdier
 vincent.bourd...@gmail.com wrote:
  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 function as expected, I need to cast it :
 
 
  typedef int(*Pupdate)(const char* path, const char* id,
 bool
  first_time);
  Pupdate update;
  update = (Pupdate) dll-getProcAddress(update);
 
  If I do not cast, the compiler do not want to use a void* when I call
 the
  function next...
 
  It is the behavior/use you were expecting when writing this class ? or
 is
  there someting else to use, avoiding the cast ...
  A little precision : this code have to work on every osg supported
  plateform. (win and linux at least)
 
 
  2.
  Next, I just have red a lot of code on osgDB, writers, plugins ... etc
 but I
  didn't found the rela connection between the osgDB core and the
 plugins.
 
  What I've understood is :
  The core, using the file termination, load the DLL (if exists).
  But the getProcAdress is never used ... so how did the core call the dll
  read/write function without the ProcAdress ?
 
 
  Any help would a very apreciated :-)
 
  Thanks.
 
  Regards,
 Vincent.
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 

 Hi Vincent,

 void* is accepted form of an address in memory. getProcAddress returns
 address of a symbol in the dynamic library and it (the underlying
 implementation) doesn't care how exported symbol looks like (i.e.
 types), nor knows what will that address be used for. There may be
 implementations around (IIRC, with boost::function and boost::bind)
 but it may be too complicated and doesn't simplify your job anyway.

 Ismail
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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 ;)

As to the getProcAddress:
as far s I know this is just a wrapper for the getProcAdress of a OS function. 
So it always returns void. In plugins it isn't used, or at least, I do not 
remember any plugin which use it. However you can use it for your own things. 
If you take a look into CUDA example from osgPPU, then you will see how I use 
that method in order to get the unit module initialized.

Cheers,
art


Vincent.B wrote:
 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 use each time a plugin dll have 
 to be loaded.
 But, there is no utilization, at no place ! So how can the osgDB core find 
 the good methods in the dLL without using this method ?
 I'm not a c++ master, but for now, I feel lost in the c++ myst ...
 


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=12079#12079





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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 procName)

is for me the only one which the loader must use each time a plugin dll
have to be loaded.
But, there is no utilization, at no place ! So how can the osgDB core
find the good methods in the dLL without using this method ?
I'm not a c++ master, but for now, I feel lost in the c++ myst ...


Interesting questions!
Reader/Writers create a static instance osgDB::RegisterReaderWriterProxyCLASS in their 
implementation (look for the REGISTER_OSGPLUGIN macro, defined in osgDB/Registry).


This static is automatically create when the plugin is loaded.  The 
RegisterReaderWriteProxy constructor creates an object of the appropriate class (such as 
ReaderWriterOBJ) and adds it to the Registry singleton.


So no call to getProcAddress() is necessary.

Hope this helps.
Cheers,
/ulrich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

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 want to reproduce that behavior on dll which is not osg based, I can
do similar things just with these informations ?

Thanks.

Regards,
   Vincent.

2009/5/14 Ulrich Hertlein u.hertl...@sandbox.de

 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 procName)

 is for me the only one which the loader must use each time a plugin dll
 have to be loaded.
 But, there is no utilization, at no place ! So how can the osgDB core
 find the good methods in the dLL without using this method ?
 I'm not a c++ master, but for now, I feel lost in the c++ myst ...


 Interesting questions!
 Reader/Writers create a static instance
 osgDB::RegisterReaderWriterProxyCLASS in their implementation (look for
 the REGISTER_OSGPLUGIN macro, defined in osgDB/Registry).

 This static is automatically create when the plugin is loaded.  The
 RegisterReaderWriteProxy constructor creates an object of the appropriate
 class (such as ReaderWriterOBJ) and adds it to the Registry singleton.

 So no call to getProcAddress() is necessary.

 Hope this helps.
 Cheers,
 /ulrich

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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 things...  ?


Not a static function but a static variable.  And yes, this is standard C behaviour that 
static variables are initialized.


Cheers,
/ulrich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

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(...)

#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 see what does this declaration can do ..

Thanks.

Regards,
   Vincent

2009/5/14 Ulrich Hertlein u.hertl...@sandbox.de

 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 things...  ?


 Not a static function but a static variable.  And yes, this is standard C
 behaviour that static variables are initialized.


 Cheers,
 /ulrich
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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 see what does this declaration can do ..


No idea.
It's referenced by the USE_OSGPLUGIN macro (function pointer passed to 
PluginFunctionProxy) and called but since it's empty there's not a lot happening.


Ah... it's used to force linkage against a certain plugin library to produce a static 
executable.  See examples/osgstaticviewer.


Cheers,
/ulrich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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 initialize 
your class. Here is a code example, which is a standard C++ and it will 
initialize your objects when loading the dll:

Code:


#include Registry

class myClass
{
   myClass()
   {
Registry::registerMe(this);
   }
};

static myClass g_myclass;




This should be almost enough to achieve what you want. 


 
 A last point I would like to understand : 
 
 in each plugin, there is the magic : 
 REGISTER_OSGPLUGIN(...)
 
 #define REGISTER_OSGPLUGIN(ext, classname) 
     extern C void osgdb_##ext(void) {} 
     static osgDB::RegisterReaderWriterProxyclassname g_proxy_##classname;
 

So as you see REGISTER_OSGPLUGIN do exactly the same, what you can see from the 
code above.

What is this extra function osgdb_ext(){} good for, I do not know. Maybe the 
idea was to implement some extra procedures inside of the dll, so that they 
could manually be called when loading the dll.

cheers,
art

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=12093#12093





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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