Re: [reSIProcate] Contents static initializers
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