Re: [boost] Any interest in static plugins?

Subject: Re: [boost] Any interest in static plugins?
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-11-30 08:01:27

I'll just add that the order of static initialisers are deterministic for
variables created within the same compilation unit, and its in order of
declaration. But you have no control over the total ordering of the linking
of the compilation units in C++, so this is small compensation.

On Mon, Nov 30, 2009 at 11:58 PM, Christian Schladetsch <
christian.schladetsch_at_[hidden]> wrote:

> Greetings,
>
> The key things to understand here are construction ordering and namespace
> pollution.
>
> 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.
>
> Given that, using such an approach to build a factory model is irrational.
> 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.
>
> I thought that these days, such issues are generally well-known. If you
> want to do this sort of thing, *you must do it after main() has been
> called*. Ideally, use some code-gen as well to make it type-safe as well
> as build-time dynamic.
>
> 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 such, they
> become impossible to test in isolation and further are problematic with
> threads.
>
> This is all just a longer-worded reply with the same answer as my previous
> post: such approaches as Dave suggests are relatively common, and all are
> doomed to failure in the general case.
>
> My best advice to avoid heartbreak is to move to a localised, scoped,
> dynamically driven model, perhaps with an automated code-gen back-end.
>
> Regards,
> Christian.
>
>
> On Mon, Nov 30, 2009 at 11:41 PM, OvermindDL1 <overminddl1_at_[hidden]>wrote:
>
>> On Mon, Nov 30, 2009 at 5:25 AM, Pierre Morcello
>> <pmorcell-cppfrance_at_[hidden]> wrote:
>> > Dave van Soest wrote :
>> >>>>>I just tested this functionality in a dynamically loaded library and
>> that works now too.
>> >
>> > Does it work correctly with static member of templated classes for
>> example? I have always had problem of conflicts for those. I mean conflicts
>> like a creation of static members copy instead of a reuse of a shared static
>> instance (when one dll use another one dll) ... -Please note that I am no
>> dll expert -.
>>
>> For note, let me give my use case.
>>
>> I have one class, say ConsoleCommands, and it is a singleton designed
>> in such a way that it is constructed upon the first call to
>> GetInstance (and it does not even attempt to construct it, just
>> returns its pointer if you call GetInstancePtr).
>>
>> I have things called ConsoleCommand that, as an example, can be called
>> like this:
>>
>> ConsoleCommand cmd_help("help", &cmd_helpHandler, "Displays the help
>> menu");
>>
>> Internally it basically calls
>> ConsoleCommands::GetInstance.RegisterCommand("help", &cmd_helpHandler,
>> "Displays the help menu");
>>
>> That will construct a ConsoleCommands if necessary (which is nothing
>> but an unordered_map essentially, nothing I need to worry about being
>> run before main).
>>
>> It is not necessarily pretty, but I have been using it for near ten
>> years and never had a problem with it yet.  I occasionally do other
>> things that make such registrations as well, so if he made a more
>> useful interface for it all so I do not need to make 3 helper structs
>> (only one of which actually holds data, the others are empty), then I
>> would be for it, but only if it really is easier.  And yes, my method
>> works across DLL boundaries (since my code is designed to allow the
>> hot-plugging and removing of commands for the console for example).
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>
>