Google 网上论坛不再支持新的 Usenet 帖子或订阅项。历史内容仍可供查看。

Destruction of objects with static storage duration

已查看 31 次
跳至第一个未读帖子

Martin Vejnár

未读,
2010年9月20日 13:42:242010/9/20
收件人
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

未读,
2010年9月20日 23:46:072010/9/20
收件人
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

未读,
2010年9月22日 16:38:262010/9/22
收件人
> 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

未读,
2010年9月24日 17:06:062010/9/24
收件人
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

未读,
2010年9月30日 03:53:332010/9/30
收件人

> > 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

未读,
2010年10月1日 15:03:062010/10/1
收件人
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 个新帖子