Re: question re. usage of "static" within static member functions of a class

From:

Joshua Maurice <joshuamaurice@gmail.com>

Newsgroups:

comp.lang.c++

Date:

Tue, 8 Sep 2009 15:35:53 -0700 (PDT)

Message-ID:

<bda1f59c-d1df-4f89-9141-1cf3de5e61e5@u16g2000pru.googlegroups.com>

On Sep 8, 3:30 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:

On Sep 8, 2:41 am, Francesco <entul...@gmail.com> wrote:

On Sep 8, 8:12 am, Paavo Helde <pa...@nospam.please.ee> wrote:

Francesco <entul...@gmail.com> kirjutas:

On 7 Set, 23:25, Paavo Helde <pa...@nospam.please.ee> wrote:

Pavel <dot_com_yahoo@paultolk_reverse.yourself> kirjutas:

Shrikumar wrote:

Thanks for the quick reply, Chris.
I was wondering about the static pointer part - I have always s=

een

static variables (that are not pointers) in use, but never a
static pointer (even if it is to guarantee that the singleton
always returns the *same* instance of the Class). Is a static
pointer (as in the instance function) a perfectly valid use of =

the

"static" keyword?

It is valid to declare pointers static if that's what you mean. =

a side note, I think they could avoid both using pointer and the
memory leak (which may be harmless in this case though) as follo=

ws:

{
static Data model;
return &model;
}

This brings along the destruction problems at the end of the progr=

am.

The singleton might be destroyed too early this way, when some cod=

still might need access to it. When created dynamically, this prob=

lem

does not occur, and the memory is reclaimed by the OS upon process
exit anyway, so there is no memory leak anyway. The singleton
destructor is not run in this case, so one should not put somethin=

essential there.

Ahhhrgh! Thanks a lot for pointing this out - I was just stomping o=

the same problem with my suggestion.

So then, if I got your post right Paavo: in order to circumvent the
destruction-order problem I should create the singleton instance as=

dynamic object _and_ I should not free it in the destructor -
otherwise I would be throwing in the destruction-order problem agai=

Side question - once I'm there - is the following fine?

-------
Data& Data::instance() {
static Data* model = new Data();
return *model;
}

Yes I think this is fine, my singletons typically look alike.

Good to know, I suppose the following should be fine too:

-------
Data& Data::instance() {
     static Data& model = *(new Data());
     // or also, simply:
     // static Data& model = *new Data;
     return model;}

-------

Someone know offhand the rules for extending the life of a temporary
which is bound to a static reference? Would the temporary here die as
soon as the first function invocation ends? Will it be destroyed
during static de-initialization? I'd instead suggest:

Data& Data::instance()
{ static Data* model = new Data();
return *model;

}

Ack, hit submit early. I'd suggest that \with\ the caveat "Insert
extra code to make concurrent calls thread-safe if needed", generally
by doing
namespace { bool force_init = (Data::instance(), true); }
which works in most cases (aka where there are no non-trivial threads
before main, or before dlopen or equivalent if this is in the static
init of a dll).