Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Destruction of objects with static storage duration

31 views
Skip to first unread message

Martin Vejnár

unread,
Sep 20, 2010, 1:42:24 PM9/20/10
to
Hi,

I have a question regarding the destruction objects with static storage
duration.

Consider the following program:

struct s { ~s(); };
struct t { ~t() { static s a; } };

int main()
{
static s b;
static t c;
}

By the time the execution leaves main, only the static objects `b` and `c`
are constructed.

C++03, 3.6.3/1 states: "Destructors for *initialized* objects of static
storage duration [...] are called as a result of returning from `main` and
as a result of calling `exit`" (emphasis mine). The C++0X FCD states
something similar. Therefore, the objects `c` and `b` are destroyed in that
order. However, during the destruction of `c`, the object `a` gets
constructed.

Since the object `a` wasn't initialized when `main` was left, will the
program exit without destroying `a`?

Best regards,
--
Martin


[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use
mailto:std...@netlab.cs.rpi.edu<std-c%2B%2...@netlab.cs.rpi.edu>
]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Krzysztof Żelechowski

unread,
Sep 20, 2010, 11:46:07 PM9/20/10
to
Martin Vejnár wrote:

>
> Consider the following program:
>
> struct s { ~s(); };
> struct t { ~t() { static s a; } };
>
> int main()
> {
> static s b;
> static t c;
> }
>
> By the time the execution leaves main, only the static objects `b` and `c`
> are constructed.
>
> C++03, 3.6.3/1 states: "Destructors for *initialized* objects of static
> storage duration [...] are called as a result of returning from `main` and
> as a result of calling `exit`" (emphasis mine).
>

> Since the object `a` wasn't initialized when `main` was left, will the
> program exit without destroying `a`?
>

The statement you quoted does not say that it covers only objects
initialised _before_ the return statement was executed.

IMHO,
Chris

--


[ comp.std.c++ is moderated. To submit articles, try just posting with ]

[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]

Ashutosh

unread,
Sep 22, 2010, 4:38:26 PM9/22/10
to
> mailto:std-...@netlab.cs.rpi.edu<std-c%2B...@netlab.cs.rpi.edu>

> ]
> [ --- Please see the FAQ before posting. --- ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html ]

Yes, its true all the object should destruct weather they are static
or constructed after main function's return statement (object a).
The quated statement does not says that it does not destroy object
created after return statement.

-Ashutosh

--


[ comp.std.c++ is moderated. To submit articles, try just posting with ]

[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]

David Krauss

unread,
Sep 24, 2010, 5:06:06 PM9/24/10
to
On Sep 20, 12:42 pm, Martin Vejnár <ava...@ratatanek.cz> wrote:
> Hi,
>
> I have a question regarding the destruction objects with static storage
> duration.
>
> Consider the following program:
>
>    struct s { ~s(); };
>    struct t { ~t() { static s a; } };
>
>    int main()
>    {
>        static s b;
>        static t c;
>    }
>
> By the time the execution leaves main, only the static objects `b` and `c`
> are constructed.
>
> C++03, 3.6.3/1 states: "Destructors for *initialized* objects of static
> storage duration [...] are called as a result of returning from `main` and
> as a result of calling `exit`" (emphasis mine).

The very next sentence begins, "These objects are destroyed in the
reverse order of the completion of their constructor..."

So, it might be a test of your implementation, whether it is able to
make a new record of static construction during static destruction,
but it's just another application of the usual rule. Destruction
always occurs in the reverse order of construction.

LongHeadersA.txt

James Kanze

unread,
Sep 30, 2010, 3:53:33 AM9/30/10
to

> > Consider the following program:

Except when it doesn't. Destruction of static variables is
in the reverse order of construction, as is the destruction
of subobjects within a larger object and the destruction of
local variables. Temporaries which are destructed at the
end of the full expression are destructed in reverse order
as well, but not all temporaries are destructed at the end
of the full expression. Other cases where reverse order is
not respected are return values and exceptions (with respect
to any temporaries used in the expression which creates
them). And of course, there's no ordering between
temporaries, static variables and local variables.

--
James Kanze

--


[ comp.std.c++ is moderated. To submit articles, try just posting with ]

[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]

David Krauss

unread,
Oct 1, 2010, 3:03:06 PM10/1/10
to
On Sep 30, 2:53 am, James Kanze <james.ka...@gmail.com> wrote:

> Except when it doesn't. Destruction of static variables is
> in the reverse order of construction, as is the destruction
> of subobjects within a larger object and the destruction of
> local variables. Temporaries which are destructed at the
> end of the full expression are destructed in reverse order
> as well, but not all temporaries are destructed at the end
> of the full expression. Other cases where reverse order is
> not respected are return values and exceptions (with respect
> to any temporaries used in the expression which creates
> them).

Those are all instances of lifetime extension, described in 12.2/4-5
(with references sprinked, e.g. in the return statement clause). It's
fundamentally impossible to preserve temporaries across a function
return, and then destroy them. (Eh, fine, you could use reference-
counting or garbage collection, or maybe even a specialized list data
structure, but that's not C++.) Likewise for exceptions. As for
binding a temporary to a reference, that's something we do on purpose.
Although it can be tricky, at least you know when you've declared a
const&.

> And of course, there's no ordering between
> temporaries, static variables and local variables.

Then the program would be a kind of palindrome.

--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use

mailto:std...@netlab.cs.rpi.edu<std-c%2B%2...@netlab.cs.rpi.edu>

0 new messages