"So I don't construct constants and use bad code instead"
Can you explain me why creating objects at local scope and only when they're really needed is considered "bad code"?
I'm not talking now about the problem in this thread, but rather about its generalization. Why
void SomeClass::foo()
{
// we don't need this constant anywhere except in this function
const Something blah(888);
// ... some code ...
}
is worse than
// literally hundreds of non-trivial global constants omitted
void SomeClass::foo()
{
// ... some code ...
}
? I always thought the opposite is true.
You don't know why the browser starts slowly. You don't know either how long the construction takes and how relevant it really is, because you have never measured it. You are just guessing.
Uhm, okay, you got me this time. I don't even want to know why that browser starts so slowly, it's simplier to switch to a different one.
But I know why one of programs that I was working on was starting slowly. Unless the profiler was just a random number generator in disguise, the global constructors (and stupid fellow programmers - how stupid one has to be to perform a lot of I/O in a constructor of global object (moreover, it was a constant!) and to make just about everything global?) were guilt.
It's just bad style to evoke undefined behaviour (union-cast) because of a non-existing problem.
As Laurent showed us, it's perfectly possible to get rid of union cast in this case.
The one who told you that probably meant constructions of depending modules shouldn't happen at global level since the initialization order is undefined.
The real reason was that sometimes they were not called, since the runtime never supported them properly.