By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,486 Members | 1,589 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,486 IT Pros & Developers. It's quick & easy.

lifetime of global statics vs. statics in functions

P: n/a
I have a problem with static lifetime (order of destruction of statics
within different cpp files). I have a workaround that happens to work
in my case. I'd like to know if this is luck or required to work.

Consider:
class A {
...
static B m_b;
static C& GetC();
};

and in cpp:

C A::m_b;
C& A::GetC()
{
static C c;
return c;
}

and in some other cpp:
static A myA;

The problem I had was with B: A::m_b was destroyed before myA. When I
switched it to be done as a static function with static variable, all
seemed fine. Luck or correct? If luck, how do I ensure myA gets
cleaned up before class A's class variables?

Stuart

Jul 27 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Stuart MacMartin wrote:
I have a problem with static lifetime (order of destruction of statics
within different cpp files). I have a workaround that happens to work
in my case. I'd like to know if this is luck or required to work.

Consider:
class A {
...
static B m_b;
static C& GetC();
};

and in cpp:

C A::m_b;
Did you mean

B A::m_b;

???
C& A::GetC()
{
static C c;
return c;
}

and in some other cpp:
static A myA;

The problem I had was with B: A::m_b was destroyed before myA.
It's probably because it was constructed _after_ 'myA'.
When I
switched it to be done as a static function with static variable, all
seemed fine. Luck or correct?
Both, I guess. The initialisation order of static data across translation
units is unspecified.
If luck, how do I ensure myA gets
cleaned up before class A's class variables?


Make sure that 'myA' is the last one to be constructed.

V
Jul 27 '05 #2

P: n/a
> Did you mean
B A::m_b;
Yes, sorry.
It's probably because it was constructed _after_ 'myA'. Not sure which you meant by "it"
Make sure that 'myA' is the last one to be constructed.

Are you saying that order of destruction is reverse of order of
construction?

And how does this help me: how do I control the order of construction?

Stuart

Jul 27 '05 #3

P: n/a
Stuart MacMartin wrote:
Did you mean
B A::m_b;

Yes, sorry.

It's probably because it was constructed _after_ 'myA'.


Not sure which you meant by "it"


A::m_b. What else could I mean? You only mentioned two objects in your
statement.
Make sure that 'myA' is the last one to be constructed.


Are you saying that order of destruction is reverse of order of
construction?


Absolutely.
And how does this help me: how do I control the order of construction?


Put them all in the same translation unit. They will be constructed in
the order of definition.

V
Jul 27 '05 #4

P: n/a
>> Are you saying that order of destruction is reverse of order of
construction?
Absolutely.


Stroustrup, 7.1.2: "A local variable is initialized when the thread of
execution reaches its definition. By default, this happens in every
call of the function and each invocation of the function has its own
copy of the variable. If a local variable is declared /static/, a
single, statically allocated object will be used to represent that
variable in all calls of the function. It will be initialized only the
first time the thread of execution reaches its definition."

Also: "The destructors for local static objects are invoked in the
reverse order of their construction when the program terminates.
Exactly when is unspecified." (10.4.8)

I assume this is only talking about statics declared in the same
function.
Is there a similar clause for statics declared in the same file?
Put them all in the same translation unit. They will be constructed in the order of definition.


This is problemmatic. Both classes are utility classes. I can't put
all application globals into a utility library.

Stuart

Jul 27 '05 #5

P: n/a
Stuart MacMartin wrote:
Are you saying that order of destruction is reverse of order of
construction?
Absolutely.

Stroustrup, 7.1.2: "A local variable is initialized when the thread of
execution reaches its definition. By default, this happens in every
call of the function and each invocation of the function has its own
copy of the variable. If a local variable is declared /static/, a
single, statically allocated object will be used to represent that
variable in all calls of the function. It will be initialized only the
first time the thread of execution reaches its definition."

Also: "The destructors for local static objects are invoked in the
reverse order of their construction when the program terminates.
Exactly when is unspecified." (10.4.8)

I assume this is only talking about statics declared in the same
function.


Wrong assumption. All statics are destroyed when the program terminates.
Is there a similar clause for statics declared in the same file?


There is nothing special about statics declared in a function or declared
outside of any function or static data members. They are all destroyed
after 'main' returns or when 'exit' is called, in the order reverse to
their respective initialisation.

Even though it is unspecified when two static objects defined in different
translation units are initialised relatively to each other, once they have
been initialised, the order of their destruction is predetermined -- the
reverse of the _factual_ order of their initialisation.
Put them all in the same translation unit. They will be constructed in the order of definition.

This is problemmatic. Both classes are utility classes. I can't put
all application globals into a utility library.


You will need to establish the dependency between them somehow, anyway.
Make one of them dynamic. Why do you care how they are disposed of?
Could it be that this dependency is actually extraneous?

V
Jul 27 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.