Re: Can initialization of static class members be forced before main?
On 3 avr, 19:34, Carsten Fuchs <CarstenFu...@T-Online.de> wrote:
Marcel M=FCller wrote:
[...]
Your Problem is not main() but the initialization sequence
of the static objects. Your repository is static as well and
there is no guarantee the this global list is initialized
before the desired classes.
Either do the lifetime-management of this singleton (the
static list) on your own by providing a getInstance() method
or ensure that the insert to the list is done by a function
in the same translation unit where the list is defined.
Oh, I'm using a getInstance() method for accessing the list
already in order to avoid static order initialization
problems, sorry for not having pointed that out in my earlier
post.
The problem is that some of my classes just aren't in that
list after main() has begun. This is because they are in
translation units of their own, and the compiler apparently
deferred their initialization until before first use, rather
than initializing all of them before main().
That's strange, because I've used this idiom with many
compilers, and I can assure you that it works. Very well, in
fact.
Are you sure that everything is correctly linked in, and that
you're not trying to do any funny business with dynamic linking.
(I've also made it work with dynamic linking, but in those
cases, is was done intentionally, to control dynamically what
was available in the list, and to be able to add modules to the
list without stopping the application.)
In fact, when a class is missing in the list after main() has
begun, and I then actually and explicitly *use* the static
typeinfo member of that class, I can see how the constructor
of that typeinfo member is run (because it adds itself to the
global list and prints some debug output).
Pseudocode:
int main()
{
print(ListOfRegisteredClasses); // Most are missing.
// Explicitly use one of the typeinfos of a missing class:
std::cout << WindowT::typeinfo.classname;
// Verify that the ctor of WindowT::typeinfo has run:
print(ListOfRegisteredClasses); // WindowT is there now.
return 0;
}
("Using" the static typeinfo member is by the way not as easy
as it seems, a real memory read or write operation must be
involved, or otherwise the compiler is clever enough to just
do nothing and to further defer the ctor call. I.e.,
(void)WindowT::typeinfo and similar statements like simple
if-tests just do nothing.)
It sounds like some sort of implicit dynamic loading is
occuring.
In summary, what is actually needed is a way to have to
compiler and/or linker initialize all nonlocal objects with
static storage duration before main() begins, without
deferring the initialization until before the first use...
Most of my experience is under Unix systems, but the little I've
done under Windows seems to work as well. Just make sure that
the relevant code is statically linked.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34