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

From:

Francesco <entuland@gmail.com>

Newsgroups:

comp.lang.c++

Date:

Wed, 9 Sep 2009 00:34:35 -0700 (PDT)

Message-ID:

<f902d564-ec88-4190-ad84-69c9dd8b03d2@j19g2000yqk.googlegroups.com>

On Sep 9, 12:35 am, Joshua Maurice <joshuamaur...@gmail.com> wrote:

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=

seen

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

f the

"static" keyword?

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

.. On

a side note, I think they could avoid both using pointer and t=

memory leak (which may be harmless in this case though) as fol=

lows:

{
static Data model;
return &model;
}

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

gram.

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

ode

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

oblem

does not occur, and the memory is reclaimed by the OS upon proce=

exit anyway, so there is no memory leak anyway. The singleton
destructor is not run in this case, so one should not put someth=

ing

essential there.

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

the same problem with my suggestion.

So then, if I got your post right Paavo: in order to circumvent t=

destruction-order problem I should create the singleton instance =

as a

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

ain.

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?

What temporary, exactly?

I'd instead suggest:

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

}

The code you posted above has already been mentioned.

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

The above isn't clear to me. What's the difference between this:
namespace { bool force_init = (Data::instance(), true); }
and this:
namespace { Data::instance(); }
assuming the important part is calling Data::instance()? Where should
force_init be used?

In any case, thanks for pointing it out, calling Data::instance()
directly in the module should ensure that the singleton gets
instantiated before main() starts, I suppose.

Best regards,
Francesco