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@gmail.com> wrote:
Dave van Soest wrote :
I just tested this functionality in a dynamically loaded library and
On Mon, Nov 30, 2009 at 5:25 AM, Pierre Morcello <pmorcell-cppfrance@yahoo.fr> wrote: 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