Re: global and static object
George wrote:
Thanks Alex,
1.
"George" wrote:
It is CRT, not C++ Runtime library calls start-up code to call
constructor
of global/static variable?
I'm not sure which of them exactly calls c'tors and d'tors of a
global object. Anf, frankly, I don't care as long as it works.
It's internal detail of CRT.
CRT is C stuff and constructor/destructor is C++ stuff. I do not understand
how CRT could understand C++ stuff and call constructor and destructor. Any
comments?
2.
Back to my original question, I can not think of a scenario when
global/static variable of ATL classes' constructor/destructor are not called.
In my understanding, all EXE/DLL C++ code links explicitly with CRT or C++
Runtime Library, and constructor/destructor will be trigged by them.
Could you find a scenario when CRT/C++ Runtime Library is not linked with a
C++ EXE/DLL?
George:
I have to say that I always thought that the C Runtime (CRT) just contained
implementation of the C standard library (printf, strlen, etc) and the C++
runtime just contained implementation of the C++ standard library (iostream,
string, STL, etc).
If you use dynamic linking then you must distribute the appropriate runtime. If
you do not use the C++ library, then I am pretty sure that you do not need to
distribute the C++ DLL. You might think that if you do not use any functions of
the C standard library you would not need to distribute the CRT DLL either, but
I think for an executable project this is not true (though it is for a DLL project).
[All this is actually irrelevant for me. First of all, all my distributed
applications are MFC applications, and MFC certainly uses the C standard library
(but not the C++ library, AFAIK). Secondly, I always use static linking, so I
never worry about any of this.]
As to your question, I would have thought that construction and destruction of
global/static objects was part of the core language rather than implemented in
the C or C++ runtime. But it seems this is wrong.
I agree that it may seems surprising that this functionality is handled by the C
runtime rather than the C++ runtime. Perhaps this is done in order to make the
C++ runtime an optional component of any C++ project.
--
David Wilkinson
Visual C++ MVP