Re: Assign Reference to another Referance

From:

cpisz <cpisz@austin.rr.com>

Newsgroups:

comp.lang.c++

Date:

Fri, 25 Sep 2009 09:23:15 -0700 (PDT)

Message-ID:

<d90a21ba-9b8f-48ce-97f0-5f3a6a87b67f@m20g2000vbp.googlegroups.com>

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

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

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.