From: Scott Woods (scottw_at_[hidden])
Date: 2003-09-24 19:30:57
> Alexander Nasonov <alnsn-mycop_at_[hidden]> writes:
> > Any interest in static_list class?
> It's a nice idea to formalize this. I've used the idiom in the past.
> The one *major* problem with it is that a translation unit's static
> initialization is not required to happen until such time as some
> function in that translation unit is invoked. The result is that you
> can't simply link together TUs which contain some class description
> and the associated registration object, and expect the registration to
> Ultimately, to be reliable, you need explicit calls to initialization
> functions :(, which makes this technique much less useful than it
> could be.
Nice idea and have had similar problems (as above).
Thought that the criteria for inclusion of a library module
into the executable image was "any reference to a symbol",
i.e. not limited to functions?
Have tried several different approaches to fix the "problem"
and basically couldnt really beat it. As long as you use libraries
(as opposed to straight objs) as one of your engineering tools
your hosed but the effort did result in some spin-offs.
Tried a "declaration" mechanism. A software version of
C++ declarations like "extern T t;". These appeared in
any "user" or "client" code. Logically complemented the
"registration" that was assumed to exist in another module.
Of course it ran into the same problem that Dave mentioned.
Now using this "as is" cos its a cute means of changing
an executable just by including or excluding the file
from the build. The "users" or "clients" can test the state
of their "declaration" - was it matched with a registration?
Also maintain a separate file.cpp with "static references" to
stuff required in the final executable. If your spelling checker
function "spellChecker_en()" was in a library somewhere
then (hack only);
void (* r_spellChecker_en )() = spellChecker_en;
also does the trick without having to actually call anything.
Its a bugger to have to maintain the references though:-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk