atexit
Fraser Ross
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
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.
Alf P. Steinbach
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
Fraser Ross
>* 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.
Alf P. Steinbach
> "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?
Fraser Ross
> 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.
Alf P. Steinbach
> "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!).
Fraser Ross
> 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.
Alf P. Steinbach
>> 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
On second thoughts, there should.
Darn, I'm cross-eyed.
Argh.
James Kanze
> "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:james...@gmail.com
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
Fraser Ross
>* 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.
James Kanze
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.
Pete Becker
> On Jul 26, 12:00 pm, "Fraser Ross" <z...@zzzzzz.com> 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.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
Fraser Ross
Fraser.
James Kanze
> James Kanze wrote:
> > On Jul 26, 12:00 pm, "Fraser Ross" <z...@zzzzzz.com> 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.)
Pete Becker
> On Jul 26, 5:37 pm, Pete Becker <p...@versatilecoding.com> wrote:
>> James Kanze wrote:
>>> On Jul 26, 12:00 pm, "Fraser Ross" <z...@zzzzzz.com> 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.
Fraser Ross
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.
James Kanze
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:-).)
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.
Alf P. Steinbach
Please post this to [comp.std.c++].
Cheers,
- Alf
Fraser Ross
to moderated groups.
Fraser.