Re: Assign Reference to another Referance

From:

cpisz <cpisz@austin.rr.com>

Newsgroups:

comp.lang.c++

Date:

Thu, 24 Sep 2009 23:44:20 -0700 (PDT)

Message-ID:

<7ba017c0-dc42-4055-ae5b-1cc272281597@m11g2000vbl.googlegroups.com>

On Sep 25, 1:41 am, cpisz <cp...@austin.rr.com> wrote:

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/bca4=

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 hav=

any destructor, meaning that the pointer retains its value regardless o=

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.
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.

Easy to get around by checking dependancies in a small project. In a
large project on which many people will be working simotaneously
(almost any job), not worth the hassle.- Hide quoted text -

- Show quoted text -

I'll add that calling GetInstance is hardly ever done directly when
this problem arises....
Lot's of debugging fun that can be easily avoided.