< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] Contents static initializers


Ever the doubting Fluffy.

Yeah, C++ might be considered broken with respect to static initializers.
If we feel that even this careful application of statics is too risky,
we can remove the init() calls in the header files and move them to main.

We can't put the content intializers in the stack. Only the app knows the
content types it wishes to handle. The current scheme allows most applications
to specify that it handles a content type by including it, and allows those
applications that can't use the include mechanism to explicitly init.

It is always possible to get in trouble with static initializers by creating
order dependecies among the initializers. The contents/factory do not invoke any
  derived contents methods until runtime. (I exagerate -- there is one static
method (getStaticType) that is invoked, but it always returns a constant).

david

Quoting Cullen Jennings <fluffy@xxxxxxxxx>:

> 
> I thought long ago we just decide to force calling a init function on the
> stack to deal with all this stuff. Complex static initializes are a
> nightmare. I really hate it when my program seg faults before getting into
> main
> 
> 
> On 1/3/05 3:46 PM, "david Butcher" <david@xxxxxxxxxxxxxx> wrote:
> 
> > 
> > Hi all, 
> > 
> > Happy New Year (western).
> > 
> > I took a look at the scary static initializers for derived Contents types.
> The
> > initializers map Mime type to the contents parser/packager through the
> > ContentsFactory template. This means that including a contents type ties it
> in
> > to the factory.
> > 
> > It turns out that they are implemented correctly as far as one can get C++
> > static initializers right.
> > 
> > In some cases, it may be necessary to call FooContents::init() explicity
> in
> > main
> > to guarantee that the content type is added to the factory. I am not sure
> when
> > this will be required -- possibly in some obscure DLL cases, but it is
> always
> > safe. Perhaps someone with experience in dynamic linking can comment?
> > 
> > I fixed a few header files that had missing bits of the static initializer
> > magic. For the most part, you shouldn't have to worry about this issue --
> just
> > make sure that all concrete contents derived types have:
> > 
> > 1. a static init() method
> > 2. a namespace level bool that is inited with the init() method
> > 3. an implementation of init() (in .cxx) that creates the factory instance
> >    as a scoped static variable.
> > 
> > See SdpContents for an example of correct usage.
> > 
> > thanks,
> > david
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> 
>