Re: Assign Reference to another Referance
cpisz <cpisz@austin.rr.com> kirjutas:
On Sep 25, 11:02?am, Paavo Helde <pa...@nospam.please.ee> wrote:
cpisz <cp...@austin.rr.com> kirjutas:
On Sep 25, 12:06?am, Paavo Helde <pa...@nospam.please.ee> wrote:
Paavo Helde <pa...@nospam.please.ee> kirjutas:
cpisz <cp...@austin.rr.com> kirjutas:
On Sep 24, 4:37?pm, Paavo Helde <pa...@nospam.please.ee> wrote:
cpisz <cp...@austin.rr.com> kirjutas:
a reference around instead. Singletons have caused more
problems than
they are worth in the past, with release order in program
exit.
That's why singletons are often created dynamically and not
destroyed before program exit.
Paavo
I've never in all my reading seen a singleton pattern that did
not
involve a global or static pointer, or reference, and thus
involve
problems of dependency at program exit time when these are
released.
Could you share this pattern that side steps the problem?
See eg.
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/bca40
44
f40befc6a
Basically this comes down to:
class Singleton {
public:
? ? ? ? ?static Singleton& Instance();
? ? ? ? ?// ...
};
Singleton& Singleton::Instance() {
? ? ?static Singleton* the_singleton = new Singleton();
? ? ?return *singleton;
}
The static pointer is released at program exit,
Just a clarificition - this release is a non-op as pointer does not
have
any destructor, meaning that the pointer retains its value
regardless
of
whether the runtime considers the statics in this compilation unit
released or not. So the singleton effectively remains operative
also
later.
but the singleton itself
is never destroyed and remains intact until process exit.
Paavo- Hide quoted text -
- Show quoted text -- Hide quoted text -
- Show quoted text -
That does not circumvent the problem at all. Suppose you have a
static
or global instance of a class that calls Instance() in its
destructor.
And so?
Undefined behavior results at program exit as the order of
destruction
is not defined. The class may or may not work with a valid instance.
The order of destruction of what objects you are talking? Not the
singleton, I suppose, as this is left undestructed.
Paavo- Hide quoted text -
- Show quoted text -- Hide quoted text -
- Show quoted text -
The static pointer is destroyed, lost, zapped, before or after the
class making a call with it.
I don't care if the singleton was never destroyed, it doesnt matter.
Nothing happens to the static pointer. It is not lost nor zapped,
whatever you might mean with that. The memory page containing the pointer
is unmapped from the process virtual memory space by the OS upon program
exit, but by that time the process code is not executing any more and has
no chance to notice that.
Only if the pointer is inside a dynamically loaded library, one can have
problems if the library is unloaded from the process memory space while
some other code is still making use of it - but in this case one already
has way larger problems, for example the Instance() member function code
is also unmapped, along with all other functions from that library.
However, as the order of dynamic libraries' unload is well defined one
can take care of such problems properly.
hth
Paavo