On Linux/OSX, you can use the 'cons tructor' and 'destructor' attributes with gcc to achieve something similar to Windows DllMain
Gaetan > On Dec 18, 2014, at 08:26, Johannes Saam <[email protected]> wrote: > > they are just static variables in the cpp or h file. > > i did find a way now around it. i am using the DllMain on windwos. Which is > exactely what i need. It runs once when the dll gets loaded and everything is > setup at this point. That is only a windows solution as its a dll specifc > thing. For linux i would still need to get that static globals class going. > > to be a little more prcise... > > in my static globals class i use funcions that themselvs include a custom > string class this one has static varibles defined that those are NOT valid > when my globals class is instanciated. > > >> On Wed, Dec 17, 2014 at 3:10 PM, Colin Doncaster <[email protected]> >> wrote: >> If the static members aren’t initialized when the DSO is loaded (which seems >> like a bad design decision), then there has to be some method of MYSOFTWARE >> you need to call to initialize them - right? >> >> >>> On Dec 17, 2014, at 5:12 PM, Johannes Saam <[email protected]> wrote: >>> >>> hey! Thanks for the quick reply! >>> >>> basically i am trying to ingerate nuke in a system that itself consists of >>> lots of plugins. >>> >>> i need to in pseudo >>> >>> load plugin >>> initalize MYSOFTWARE >>> register plugins etc >>> >>> create node >>> register node in MYSOFTWARE >>> rename node emit rename to MYSOFTWARE >>> do stuff >>> delete node >>> delete node in MYSOFTWARE >>> >>> right now i have one Op and my setup wrapper. The setup wrapper itself >>> calls code in MYSOFTWARE that contains static members. >>> when my static globlas class is called the static members of MYSOFTWARE are >>> not initialized. >>> maybe i am just doing it wrong but it looks something like this >>> >>> class globals >>> { >>> globals() >>> { >>> stuff happens; >>> } >>> }_globals; >>> >>> >>> >>> myOp...... >>> >>>> On Wed, Dec 17, 2014 at 1:56 PM, Colin Doncaster >>>> <[email protected]> wrote: >>>> The static class should be fine, I’m not too sure what you mean about the >>>> order issue of the static variables? If you encapsulate everything into a >>>> single static Globals class then you’ll end up with a tidy solution. >>>> >>>> Without knowing exactly what you’re trying to do you may want to look at >>>> implementing a singleton pattern that provides a little more managed glue >>>> between Nuke and whatever you’re trying to integrate. >>>> >>>> Just be aware about symbol visibility if building multiple nuke nodes that >>>> use the same static globals. >>>> >>>> >>>> > On Dec 17, 2014, at 4:37 PM, Johannes Saam <[email protected]> >>>> > wrote: >>>> > >>>> > hey Nuke dev! >>>> > >>>> > I have another strange one... i need to setup stuff on plugin load. >>>> > What is the smartest way to run code ONCE when the plugin gets loaded? >>>> > >>>> > i researched and so far i am using a static object and in its >>>> > constructor i do my business. the problem that i am facing is that the >>>> > order of static objects is not defined. So now in my static setup class >>>> > i am calling code that itself has static variables and they are not >>>> > valid at this point. >>>> > >>>> > I am looking for the equivalent of initializePlugin in maya for example. >>>> > A space that is valid but only run ONCE as SOON as you load the plugin. >>>> > >>>> > Overall i need this and then a space on node create and delete ( i have >>>> > found the attach and dettach methods to work fine here ) as well as a >>>> > node renamed callback. This callback works fine now but really due to >>>> > the unpredictable order of static variables i would need some help with >>>> > the plugin initialize. >>>> > >>>> > Any code masters out there with new ideas? >>>> > Rock on >>>> > jo >>>> > _______________________________________________ >>>> > Nuke-dev mailing list >>>> > [email protected], http://forums.thefoundry.co.uk/ >>>> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >>>> >>>> _______________________________________________ >>>> Nuke-dev mailing list >>>> [email protected], http://forums.thefoundry.co.uk/ >>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >>> >>> _______________________________________________ >>> Nuke-dev mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >> >> >> _______________________________________________ >> Nuke-dev mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > > _______________________________________________ > Nuke-dev mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
_______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
