lifetime of global statics vs. statics in functions

Discussion in 'C++' started by Stuart MacMartin, Jul 27, 2005.

  1. 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
     
    Stuart MacMartin, Jul 27, 2005
    #1
    1. Advertising

  2. 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
     
    Victor Bazarov, Jul 27, 2005
    #2
    1. Advertising

  3. > 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
     
    Stuart MacMartin, Jul 27, 2005
    #3
  4. 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
     
    Victor Bazarov, Jul 27, 2005
    #4
  5. >> 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
     
    Stuart MacMartin, Jul 27, 2005
    #5
  6. 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
     
    Victor Bazarov, Jul 27, 2005
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jason

    Statics and connections

    Jason, Dec 6, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    1,752
    Jason
    Dec 6, 2004
  2. =?Utf-8?B?VHJhcHVsbw==?=

    Global variable lifetime

    =?Utf-8?B?VHJhcHVsbw==?=, Jan 26, 2005, in forum: ASP .Net
    Replies:
    11
    Views:
    597
    Trapulo
    Jan 26, 2005
  3. Serge Skorokhodov (216716244)

    statics in member functions

    Serge Skorokhodov (216716244), Jul 27, 2005, in forum: C++
    Replies:
    4
    Views:
    315
    Jay Nabonne
    Jul 27, 2005
  4. Replies:
    3
    Views:
    925
    Thomas Matthews
    Sep 9, 2006
  5. User1014
    Replies:
    3
    Views:
    192
    Richard Cornford
    Dec 1, 2006
Loading...

Share This Page