EDIT: I apologise, Robert said nothing about starting a thread as a result of the initialisation of a global. On Tue, Dec 1, 2009 at 12:50 AM, Christian Schladetsch < christian.schladetsch@gmail.com> wrote:
Dissenting points from my preceding post are commented on:
Rob Stewart wrote:
Depending upon platform, the use of a dynamically linked library (DLL or
shared object) may give desirable results, whereas the use of statically linked libraries will not.
Not only depending on platform, but also depending on the order of the linking of compilation units within a given DLL or other library; which is not deterministic.
[snip]
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
That is nonsensical. How can a name in a namespace pollute the global namespace? Perhaps you're trying to say that such variables contribute to the global system state.
Either or both my and the general terminology is lacking here. I don't know what the convention is for this, but to clarify: when I say 'global' I mean 'globally accessible, given matching declaration'. A variable in namespace *foo* can still be globally accessible, and remains traumatic when used in threaded applications.
In the OP's environment, such statics may well be initialized before main() runs, thus avoiding threading problems.
How could such a reprehensible act of creating a thread before main() runs avoid problems?
Regards, Christian.