Stephan:
Thank you very much for the pointer. Perhaps I do not fully
understand this, but doesn't this have the adverse effect of forcing
every class that has a static to always be linked into the application?
That is doesn't this force artifical dependencies on any class with a
static member which is initialized in the module initializer? We have
a number of users who are very concerned with code foot print size and
I would not want to cause such dependencies that make the executables
bigger than needed by linking in additional classes. In fact, I would
like to put some effort into cleaning up some of the dependencies that
we have so that executables can be smaller then they are today.
Cheers,
Dan
--- "Stephen C. Steel" <[EMAIL PROTECTED]> wrote:
> --- Daniel Petrie <[EMAIL PROTECTED]> wrote:
>
> > One of the problems that creeps up on almost every new platform
> that
> > we add support for in sipX is static initialization. We solved
> this in
> > the past by tweeking things here and there. We have had a few
> > private discussions on how to do a better job at static
> initialization in
> the
> > past and this recently came up on the list and in Jira. Lets have
> a
> > IM chat/conference to discuss this issue and how we might make it
> more
> > reliable and deterministic.
> >
> > In particular I would be interested in discussing how we might make
> a
> > framework to support static initialization that does not short
> circuit
> > dependencies in the libraries (i.e. force a dependencie upon
> everything
> > that has a static member). Please send references to existing
> > solutions or examples on how this is solved in other systems.
>
> Scott Meyers describes a good technique for ensuring that static
> Objects are initialized in the correct order in "Effective C++".
> In the first edition it's item 47: "Ensure that global objects are
> initialized before they're used". The technique has been used by
> many implementations of the iostreams library (where it ensures
> that global objects like cin, cout and cerr are properly initialized
> before any code uses it, even if that code is in another static
> object). The technique relies on standard C++ behavior, so it
> works with almost any compiler.
>
> The order in which static objects within a module are initialized
> can be controlled by declaring them all in the same source file
> in the appropriate order. The trick to ensuring that all the
> static objects in a module are initialized before you use them
> is to define a helper class for the module.
>
> So, in the header file <Module.h> we have:
>
> // class defininitions for module
>
> // declarations for Module
>
> // helper class to ensure static objects are initialized
> // before they are used
> class ModuleInit
> {
> private:
> static unsigned int count;
>
> public:
> ModuleInit();
> ~ModuleInit();
> }
>
> // declare a file static instance of ModuleInit()
> static ModuleInit() module_init;
>
> Then in the implementation file for the module we have
>
> // This will be initialized to zero before any constructors run
> unsigned int ModuleInit::count;
>
> ModuleInit::ModuleInit()
> {
> if (count++ == 0)
> {
> // initialize a static objects in Module
> }
> }
>
> ModuleInit::~ModuleInit()
> {
> if (--count == 0)
> {
> // destroy static objects in Module
> }
> }
>
> As long as any code that uses objects defined in <Module.h> includes
> this header file before declaring its own static objects, all the
> static objects in <Module.h> will be initialized before they can
> be used.
>
>
>
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
