Re: [boost] Any interest in static plugins?

Subject: Re: [boost] Any interest in static plugins?
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-11-30 08:14:52

Christian Schladetsch
>
> Greetings,

Please don't top post.  See http://www.boost.org/community/policy.html#quoting.

> When using static initialisers, you have absolutely no
> control over the
> practical ordering of those initialisations in the final
> image. One build
> may be A,B,C, the next may be C,A,B, even on the same
> platform with the same
> set of types. The ordering is effectively arbitrary from
> build to build. No, really, this is true.

Depending upon platform, the use of a dynamically linked library (DLL or shared object) may give desirable results, whereas the use of statically linked libraries will not.  For example, in our environment, static objects in an object file in a static library *will not* be initialized unless a function in the same translation unit is called (at least indirectly) from main().

> Given that, using such an approach to build a factory model
> is irrational.

Not so much irrational as misinformed or ignorant of portability considerations.

> Many types need other types in their definitions. Without a
> deterministic
> order, using static initialisation to create a factory is
> impossible. Sure,
> you can come up with and practically use toy systems with a
> given linker in
> a given configuration that have no problem. But when you have
> complex and.or
> derived types, or use dynamic linking, it becomes an
> intractable problem.

That problem is worsened when it must be portable.

> I thought that these days, such issues are generally
> well-known. If you want

There's a great deal to know and one has to go looking for it to find it.  It is easy to develop something in isolation and think it will work more broadly.

> Ideally, use some code-gen as well to make it type-safe as well as
> build-time dynamic.

Code generation is never an ideal solution, though it might be necessary to best satisfy a given set of criteria.

> The second issue is global scope pollution. Systems based on
> pre-main()
> initialisation are necessarily polluting the global namespace
> (you can hide
> the variables in a namespace, but they are still global). As

That is nonsensical.  How can a name in a namespace pollute the global namespace?  Perhaps you're trying to say that such variables contribute to the global system state.

> such, they
> become impossible to test in isolation and further are
> problematic with threads.

In the OP's environment, such statics may well be initialized before main() runs, thus avoiding threading problems.  That isn't necessarily true, but it is accepted that threads shouldn't be created via static initialization, so it isn't unreasonable to make that a requirement for using such a library.

You are certainly on point about testing being difficult in the OP's scheme.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.