lifetime of global statics vs. statics in functions

[Stuart MacMartin]

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

 

[Victor Bazarov]

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

 

[Stuart MacMartin]

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

 

[Victor Bazarov]

Yes, sorry.



Not sure which you meant by "it"

A::m_b. What else could I mean? You only mentioned two objects in your
statement.

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

 

[Stuart MacMartin]

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

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

 

[Victor Bazarov]

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.

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