Re: Assign Reference to another Referance

From:

James Kanze <james.kanze@gmail.com>

Newsgroups:

comp.lang.c++

Date:

Fri, 25 Sep 2009 01:11:56 -0700 (PDT)

Message-ID:

<d35890cf-192c-4c35-abf7-abbc41112abf@v2g2000vbb.googlegroups.com>

On Sep 25, 7: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.

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/bca4044f40befc6a

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,

I'm not too sure what you mean by "released". C++ doesn't have
a concept of "release"---do you mean "destructed", or "deleted".
(One could argue that the pointer is destructed, but that this
is a no-op. In no way is anything ever deleted, however.)

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

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.

No it doesn't. I'd suggest that you check the code again.

--
James Kanze