Re: Assign Reference to another Referance
* cpisz:
Instead of this thread growing to 90 posts each containing a different
vocabulary word. Let's please just cut and paste the standard as it
pertains to the initialization and deinitialization of:
static objects in global scope.
global objects.
and both as it pertains to built in types if you like.
I believe, although I don't have the standard with me, that it says C+
+ does not guarentee the initialization order or de-initialization
order of any of the above.
There are some guarantees.
O comeon Alf, you cannot respond with "that's meaningless drivel" and
prove anything.
True.
I'm not proving anything by that, just trying to give useful feedback.
I think the reason for the meaningless verbiage was that you confused process
entry function with C/C++ 'main' (if you did you're not alone: the Microsoft
documentation has, as long as I can remember, confused the process entry
function with 'WinMain', of all things), but I may be wrong.
Can you please post these guarentess you are claiming?
One important guarantee wrt. singletons is that, for static objects whose
constructions do not overlap in time, they're destroyed in opposite order of
construction.
If a static object A has a constructor that invokes a constructor of static
object B (construction overlap in time) then the situation is more complex.
Object B is then fully constructed before A is fully constructed, but the
construction of A started first. So what is then the destruction sequence?
In this case B might be a singleton, e.g. a logger, and it stands to reason that
if A uses that singleton in its constructor it might also use that singleton in
its destructor, and so it would be really bad if B was destroyed first. Happily
it's destroyed last, guaranteed. Example:
<code>
#include <iostream>
#include <string>
using namespace std;
struct Tattler
{
string id;
Tattler( string const& s ): id( s ) { cout << id << endl; }
~Tattler() { cout << "~" << id << endl; }
};
struct Logger
{
Tattler t;
Logger(): t( "Logger" ) {}
static Logger& instance()
{
static Logger theInstance;
return theInstance;
}
};
struct Foo
{
Tattler t;
Foo(): t( "Foo" ) { Logger::instance(); }
};
static Foo f;
int main()
{}
</code>
<example>
Foo
Logger
~Foo
~Logger
</example>
Another important guarantee is that zero-initialization of statics is performed
before dynamic initialization.
I'd love for you to make a huge impact on my life and allow for me to
use singletons again. You have once or twice before on other topics.
But all these claims that, "there is no problem" isn't convincing me
of anything. I had a problem, not once, but 5 times!
I'm not sure about what problems you mean.
There are many problems with singletons, and even more with static data that is
not wrapped as singleton.
I guess those problems are discussed further up-thread, but.
Cheers & hth.,
- Alf