atexit

Discussion in 'C++' started by Fraser Ross, Jul 25, 2009.

  1. Fraser Ross

    Fraser Ross Guest

    3.6.3/3 tells me what I want to know for non-local static objects but
    where is there the same for local static objects?

    SomeClass *pObj1(new SomeClass(1));
    Loki::SetLongevity(pObj1, 5);
    static SomeClass obj2(2);
    SomeClass *pObj3(new SomeClass(3));
    Loki::SetLongevity(pObj3, 6);

    SetLongevity registers the destructors to be called with atexit for
    pObj1 and pObj3. What should be the order of destruction?


    Fraser.
    Fraser Ross, Jul 25, 2009
    #1
    1. Advertising

  2. Fraser Ross

    Fraser Ross Guest

    int main() {
    > SomeClass *pObj1(new SomeClass(1));
    > Loki::SetLongevity(pObj1, 5);
    > static SomeClass obj2(2);
    > SomeClass *pObj3(new SomeClass(3));
    > Loki::SetLongevity(pObj3, 6);

    }

    The code is in a function.

    Fraser.
    Fraser Ross, Jul 25, 2009
    #2
    1. Advertising

  3. * Fraser Ross:
    > 3.6.3/3 tells me what I want to know for non-local static objects but
    > where is there the same for local static objects?
    >
    > SomeClass *pObj1(new SomeClass(1));
    > Loki::SetLongevity(pObj1, 5);
    > static SomeClass obj2(2);
    > SomeClass *pObj3(new SomeClass(3));
    > Loki::SetLongevity(pObj3, 6);
    >
    > SetLongevity registers the destructors to be called with atexit for
    > pObj1 and pObj3. What should be the order of destruction?


    The order of atexit calls is defined by the standard, the order of destruction
    (what those calls do or not) is defined by the Loki library.

    As I recall there is full discussion of SetLongevity et.al. in "Modern C++
    Design" by Andre Alexandrescu.

    To use Loki you really should have that book at hand.


    Cheers & hth.,

    - Alf
    Alf P. Steinbach, Jul 25, 2009
    #3
  4. Fraser Ross

    Fraser Ross Guest

    "Alf P. Steinbach"
    >* Fraser Ross:
    >> 3.6.3/3 tells me what I want to know for non-local static objects but
    >> where is there the same for local static objects?
    >>
    >> SomeClass *pObj1(new SomeClass(1));
    >> Loki::SetLongevity(pObj1, 5);
    >> static SomeClass obj2(2);
    >> SomeClass *pObj3(new SomeClass(3));
    >> Loki::SetLongevity(pObj3, 6);
    >>
    >> SetLongevity registers the destructors to be called with atexit for
    >> pObj1 and pObj3. What should be the order of destruction?

    >
    > The order of atexit calls is defined by the standard, the order of
    > destruction (what those calls do or not) is defined by the Loki
    > library.


    I know that. I don't know where in the standard that it says how atexit
    interacts with local static destruction. Anyway there seems to be a
    stack type ordering.

    >
    > As I recall there is full discussion of SetLongevity et.al. in "Modern
    > C++ Design" by Andre Alexandrescu.
    >
    > To use Loki you really should have that book at hand.

    I'm reading it. It doesn't explain every detail. The whole concept of
    longevity should really be a death ordering not a lifespan length.

    Fraser.
    Fraser Ross, Jul 25, 2009
    #4
  5. * Fraser Ross:
    > "Alf P. Steinbach"
    >> * Fraser Ross:
    >>> 3.6.3/3 tells me what I want to know for non-local static objects but
    >>> where is there the same for local static objects?
    >>>
    >>> SomeClass *pObj1(new SomeClass(1));
    >>> Loki::SetLongevity(pObj1, 5);
    >>> static SomeClass obj2(2);
    >>> SomeClass *pObj3(new SomeClass(3));
    >>> Loki::SetLongevity(pObj3, 6);
    >>>
    >>> SetLongevity registers the destructors to be called with atexit for
    >>> pObj1 and pObj3. What should be the order of destruction?

    >> The order of atexit calls is defined by the standard, the order of
    >> destruction (what those calls do or not) is defined by the Loki
    >> library.

    >
    > I know that. I don't know where in the standard that it says how atexit
    > interacts with local static destruction.


    Searching for 'atexit' immediately landed me on §3.6.3/3.

    Essentially the rules ensure that static objects existing when an atexit handler
    is registered, still exist when that handler runs (i.e. not yet destroyed).

    For the purpose of ordering you might consider an atexit-handler as equivalent
    to the destructor of a hypothetical static object, and the registration as
    equivalent to a constructor of that static object.


    > Anyway there seems to be a stack type ordering.


    Yes.


    >> As I recall there is full discussion of SetLongevity et.al. in "Modern
    >> C++ Design" by Andre Alexandrescu.
    >>
    >> To use Loki you really should have that book at hand.

    > I'm reading it. It doesn't explain every detail. The whole concept of
    > longevity should really be a death ordering not a lifespan length.


    Huh?


    Cheers & hth.,

    - Alf
    Alf P. Steinbach, Jul 25, 2009
    #5
  6. Fraser Ross

    Fraser Ross Guest

    "Alf P. Steinbach"
    > Searching for 'atexit' immediately landed me on §3.6.3/3.
    >
    > Essentially the rules ensure that static objects existing when an
    > atexit handler is registered, still exist when that handler runs (i.e.
    > not yet destroyed).


    That section only refers to non-local static objects so its irrelevant.


    >>> As I recall there is full discussion of SetLongevity et.al. in
    >>> "Modern C++ Design" by Andre Alexandrescu.
    >>>
    >>> To use Loki you really should have that book at hand.

    >> I'm reading it. It doesn't explain every detail. The whole concept
    >> of longevity should really be a death ordering not a lifespan length.

    >
    > Huh?


    5 and 6 are the death order values. Longevity sounds like a lifespan
    measurement.

    Fraser.
    Fraser Ross, Jul 25, 2009
    #6
  7. * Fraser Ross:
    > "Alf P. Steinbach"
    >> Searching for 'atexit' immediately landed me on §3.6.3/3.
    >>
    >> Essentially the rules ensure that static objects existing when an
    >> atexit handler is registered, still exist when that handler runs (i.e.
    >> not yet destroyed).

    >
    > That section only refers to non-local static objects so its irrelevant.


    You're missing an apostrophe in "its".

    Anyway, it seems you have a misconception regarding what "static storage
    duration" means.

    It means any object with static storage duration, and that includes "static"
    local variables ("static storage duration" is defined by §3.7.1 -- and now,
    don't quarrel, cause I'm not going to help you more then, but darn it, read!).


    Cheers & hth.,

    - Alf
    Alf P. Steinbach, Jul 25, 2009
    #7
  8. Fraser Ross

    Fraser Ross Guest

    > Anyway, it seems you have a misconception regarding what "static
    > storage duration" means.
    >
    > It means any object with static storage duration, and that includes
    > "static" local variables ("static storage duration" is defined by
    > §3.7.1 -- and now, don't quarrel, cause I'm not going to help you
    > more then, but darn it, read!).


    I know it includes static local variables. 3.7.1/3 says 3.6.3 describes
    the destruction of local static variables. I can't see where it is.
    Anyway its determined by what gets initialised at run-time and most
    programs can run differently depending on run-time factors.

    Fraser.
    Fraser Ross, Jul 25, 2009
    #8
  9. * Fraser Ross:
    >> Anyway, it seems you have a misconception regarding what "static
    >> storage duration" means.
    >>
    >> It means any object with static storage duration, and that includes
    >> "static" local variables ("static storage duration" is defined by
    >> §3.7.1 -- and now, don't quarrel, cause I'm not going to help you
    >> more then, but darn it, read!).

    >
    > I know it includes static local variables.


    In the previous article you wrote (incorrectly), "That section only refers to
    non-local static objects so its irrelevant.", so you're contradicting yourself.



    > 3.7.1/3 says 3.6.3 describes
    > the destruction of local static variables. I can't see where it is.


    Read the very first sentence of the very first paragraph.


    > Anyway its determined by what gets initialised at run-time and most
    > programs can run differently depending on run-time factors.


    That's right.


    Cheers & hth.,

    - Alf

    PS: Forget about the apostrophe, there shouldn't be any.
    Alf P. Steinbach, Jul 25, 2009
    #9
  10. * Alf P. Steinbach:
    > * Fraser Ross:
    >>> Anyway, it seems you have a misconception regarding what "static
    >>> storage duration" means.
    >>>
    >>> It means any object with static storage duration, and that includes
    >>> "static" local variables ("static storage duration" is defined by
    >>> §3.7.1 -- and now, don't quarrel, cause I'm not going to help you
    >>> more then, but darn it, read!).

    >>
    >> I know it includes static local variables.

    >
    > In the previous article you wrote (incorrectly), "That section only
    > refers to non-local static objects so its irrelevant.", so you're
    > contradicting yourself.
    >
    >
    >
    >> 3.7.1/3 says 3.6.3 describes the destruction of local static
    >> variables. I can't see where it is.

    >
    > Read the very first sentence of the very first paragraph.
    >
    >
    >> Anyway its determined by what gets initialised at run-time and most
    >> programs can run differently depending on run-time factors.

    >
    > That's right.
    >
    >
    > Cheers & hth.,
    >
    > - Alf
    >
    > PS: Forget about the apostrophe, there shouldn't be any.


    On second thoughts, there should.

    Darn, I'm cross-eyed.

    Argh.
    Alf P. Steinbach, Jul 25, 2009
    #10
  11. Fraser Ross

    James Kanze Guest

    On Jul 25, 10:12 pm, "Fraser Ross" <> wrote:
    > "Alf P. Steinbach"


    > > Searching for 'atexit' immediately landed me on §3.6.3/3.

    >
    > > Essentially the rules ensure that static objects existing
    > > when an atexit handler is registered, still exist when that
    > > handler runs (i.e. not yet destroyed).


    > That section only refers to non-local static objects so its
    > irrelevant.


    Where do you get that? It's not in my copy of the standard
    (2003); it wasn't in the 1998 version either, nor in the ARM.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jul 26, 2009
    #11
  12. Fraser Ross

    Fraser Ross Guest

    "Alf P. Steinbach"
    >* Fraser Ross:
    >>> Anyway, it seems you have a misconception regarding what "static
    >>> storage duration" means.
    >>>
    >>> It means any object with static storage duration, and that includes
    >>> "static" local variables ("static storage duration" is defined by
    >>> §3.7.1 -- and now, don't quarrel, cause I'm not going to help you
    >>> more then, but darn it, read!).

    >>
    >> I know it includes static local variables.

    >
    > In the previous article you wrote (incorrectly), "That section only
    > refers to non-local static objects so its irrelevant.", so you're
    > contradicting yourself.


    No, I'm saying that I know static local variables have static storage
    durartion.

    I've been looking at N2914. 3.6.3/3 only refers to non-local statics.

    Fraser.
    Fraser Ross, Jul 26, 2009
    #12
  13. Fraser Ross

    James Kanze Guest

    On Jul 26, 12:00 pm, "Fraser Ross" <> wrote:
    > "Alf P. Steinbach"


    > >* Fraser Ross:
    > >>> Anyway, it seems you have a misconception regarding what
    > >>> "static storage duration" means.


    > >>> It means any object with static storage duration, and that
    > >>> includes "static" local variables ("static storage
    > >>> duration" is defined by §3.7.1 -- and now, don't
    > >>> quarrel, cause I'm not going to help you more then, but
    > >>> darn it, read!).


    > >> I know it includes static local variables.


    > > In the previous article you wrote (incorrectly), "That
    > > section only refers to non-local static objects so its
    > > irrelevant.", so you're contradicting yourself.


    > No, I'm saying that I know static local variables have static
    > storage durartion.


    > I've been looking at N2914. 3.6.3/3 only refers to non-local
    > statics.


    There is no such thing as N2914. (The latest I can see is
    N2881.) Both ISO 14882:1998 and ISO 14882:2003 (as well as the
    ARM) say exactly the opposite.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jul 26, 2009
    #13
  14. Fraser Ross

    Fraser Ross Guest

    In N2691 3.6.3/3 was significantly rewritten.

    Fraser.
    Fraser Ross, Jul 26, 2009
    #14
  15. Fraser Ross

    James Kanze Guest

    On Jul 26, 5:37 pm, Pete Becker <> wrote:
    > James Kanze wrote:
    > > On Jul 26, 12:00 pm, "Fraser Ross" <> wrote:
    > >> I've been looking at N2914. 3.6.3/3 only refers to non-local
    > >> statics.


    > > There is no such thing as N2914. (The latest I can see is
    > > N2881.)


    > N2914 is the working draft in the pre-Frankfurt mailing. It's
    > dated 2009-06-22. It's now the current working draft.


    So I see. And I didn't have the latest mailings downloaded to
    my machine here.

    The wording of §3.6.3 has been completely changed with regards
    to the standard, to take into account threading and thread local
    storage. And §3.6.3 has been changed to exclude static objects
    with local scope. Is this intentional, and for what reason?
    (It may break existing programs.) Or is it an unintentional
    side effect of some other change? I presume that the intent
    here is to exclude objects with thread storage duration; if so,
    should I raise a defect report, or is the original intent clear
    enough that you could handle it as an editorial change. (It
    looks a bit big for an editorial change to me, but if the
    proposal that was actually voted on was clear, perhaps that
    would be acceptable.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jul 26, 2009
    #15
  16. Fraser Ross

    Fraser Ross Guest

    I think I know know where in 3.6.3 the description of the destruction of
    local static variables is.

    "If the completion of the constructor or dynamic initialization of an
    object with static storage duration is sequenced before that of another,
    the completion of the destructor of the second is sequenced before the
    initiation of the destructor of the first."
    Thats ok.

    "[ Note: this definition permits concurrent destruction. -end note ]"
    I'm not sure what that means.

    "If an object is initialized statically, the object is destroyed in the
    same order as if the object was dynamically initialized."
    Is this refering to statics that are constant initialised? Couldn't it
    be written better if so?


    I still can't see anything that describes the order of destruction of
    local statics in relation to registered atexit functions.

    Fraser.
    Fraser Ross, Jul 27, 2009
    #16
  17. Fraser Ross

    James Kanze Guest

    On Jul 26, 8:03 pm, Pete Becker <> wrote:
    > James Kanze wrote:
    > > On Jul 26, 5:37 pm, Pete Becker <> wrote:
    > >> James Kanze wrote:
    > >>> On Jul 26, 12:00 pm, "Fraser Ross" <> wrote:
    > >>>> I've been looking at N2914. 3.6.3/3 only refers to non-local
    > >>>> statics.


    > >>> There is no such thing as N2914. (The latest I can see is
    > >>> N2881.)


    > >> N2914 is the working draft in the pre-Frankfurt mailing. It's
    > >> dated 2009-06-22. It's now the current working draft.


    > > So I see. And I didn't have the latest mailings downloaded to
    > > my machine here.


    > > The wording of §3.6.3 has been completely changed with regards
    > > to the standard, to take into account threading and thread local
    > > storage. And §3.6.3 has been changed to exclude static objects
    > > with local scope. Is this intentional, and for what reason?
    > > (It may break existing programs.) Or is it an unintentional
    > > side effect of some other change? I presume that the intent
    > > here is to exclude objects with thread storage duration; if so,
    > > should I raise a defect report, or is the original intent clear
    > > enough that you could handle it as an editorial change. (It
    > > looks a bit big for an editorial change to me, but if the
    > > proposal that was actually voted on was clear, perhaps that
    > > would be acceptable.)


    > It's still under discussion. See N2880 and and N2917. The problem
    > centers around interactions between detached threads and destruction of
    > function-static objects.


    Ah yes. Threads still actively running while we're shutting
    down.

    I know that my own take has always been that it's undefined
    behavior, and that if you have no way to ensure that a thread
    will not be active when shutting down, don't detach it; join
    before starting shutdown. Supposing it actually matters---in a
    lot of cases, the possible "undefined behaviors" are in fact
    limited to things that might be acceptable to many programs
    during shutdown. Or you don't provide any provisions for
    shutdown at all---the only way to stop the program is to kill
    it, in which case, no destructors are run. Neither are what
    I'd call nice, but both are quick and easy to implement. When
    something cleaner is required, it's usually possible, with some
    effort, to ensure that all threads reach an "inactive" state
    before starting actual shutdown. So while I'm normally a very
    strong opponent of anything which may lead to undefined
    behavior, I do wonder if the committee isn't spending too much
    time trying to define cases that shouldn't occur in well written
    code, and are easy enough to avoid if one knows what one is
    doing. (And of course, if one doesn't know what one is doing,
    then just about everything to do with threading is potentially
    undefined behavior.) In other words: if it's a question of
    getting the standard out next meeting, with this as undefined
    behavior, or waiting a year or so in order to find a perfect
    solution (which we won't find anyway), I'd vote for right now.
    (Of course, as long as concepts were there, the people working
    on anything else had all the time in the world to do the best
    job possible:).)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jul 27, 2009
    #17
  18. Fraser Ross

    Fraser Ross Guest

    "Fraser Ross"
    >
    > I still can't see anything that describes the order of destruction of
    > local statics in relation to registered atexit functions.


    This was removed from the description of exit:
    "A local static object obj3 is destroyed at the same time it would be if
    a function calling the obj3 destructor were registered with atexit at
    the completion of the obj3 constructor."

    The description now refers to 3.6.3 but 3.6.3 does not have anything
    like the above. Something like this needs to be put into 3.6.3.

    Fraser.
    Fraser Ross, Jul 28, 2009
    #18
  19. * Fraser Ross:
    > "Fraser Ross"
    >> I still can't see anything that describes the order of destruction of
    >> local statics in relation to registered atexit functions.

    >
    > This was removed from the description of exit:
    > "A local static object obj3 is destroyed at the same time it would be if
    > a function calling the obj3 destructor were registered with atexit at
    > the completion of the obj3 constructor."
    >
    > The description now refers to 3.6.3 but 3.6.3 does not have anything
    > like the above. Something like this needs to be put into 3.6.3.
    >
    > Fraser.


    Please post this to [comp.std.c++].

    Cheers,

    - Alf
    Alf P. Steinbach, Jul 28, 2009
    #19
  20. Fraser Ross

    Fraser Ross Guest

    I'll try but my newgroup servers are possibly not configured for posting
    to moderated groups.

    Fraser.
    Fraser Ross, Jul 28, 2009
    #20
    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. Serve Laurijssen

    atexit and global destructors

    Serve Laurijssen, Jan 15, 2004, in forum: C++
    Replies:
    3
    Views:
    6,954
    tom_usenet
    Jan 15, 2004
  2. JKop
    Replies:
    8
    Views:
    448
  3. Bengt Richter
    Replies:
    0
    Views:
    280
    Bengt Richter
    Aug 25, 2004
  4. Chris Gorton

    atexit not being executed

    Chris Gorton, May 3, 2005, in forum: Python
    Replies:
    0
    Views:
    387
    Chris Gorton
    May 3, 2005
  5. David Rushby

    atexit + threads = bug?

    David Rushby, Jan 12, 2006, in forum: Python
    Replies:
    7
    Views:
    457
    David Rushby
    Jan 13, 2006
Loading...

Share This Page