This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 114a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-04-18
There are several problems with 6.7.5 [basic.stc]:
6.7.5 [basic.stc] paragraph 2 says that "Static and automatic storage durations are associated with objects introduced by declarations (6.2 [basic.def]) and implicitly created by the implementation (6.7.7 [class.temporary])."
In fact, objects "implicitly created by the implementation" are the temporaries described in (6.7.7 [class.temporary]), and have neither static nor automatic storage duration, but a totally different duration, described in 6.7.7 [class.temporary].
6.7.5 [basic.stc] uses the expression "local object" in several places, without ever defining it. Presumably, what is meant is "an object declared at block scope", but this should be said explicitly.
In a recent discussion in comp.lang.c++.moderated, on poster interpreted "local objects" as including temporaries. This would require them to live until the end of the block in which they are created, which contradicts 6.7.7 [class.temporary]. If temporaries are covered by this section, and the statement in 6.7.5 [basic.stc] seems to suggest, and they aren't local objects, then they must have static storage duration, which isn't right either.
I propose adding a fourth storage duration to the list after 6.7.5 [basic.stc] paragraph 1:
And rewriting the second paragraph of this section as follows:
Temporary storage duration is associated with objects implicitly created by the implementation, and is described in 6.7.7 [class.temporary]. Static and automatic storage durations are associated with objects defined by declarations; in the following, an object defined by a declaration with block scope is a local object. The dynamic storage duration is associated with objects created by the operator new.
Steve Adamczyk: There may well be an issue here, but one should bear in mind the difference between storage duration and object lifetime. As far as I can see, there is no particular problem with temporaries having automatic or static storage duration, as appropriate. The point of 6.7.7 [class.temporary] is that they have an unusual object lifetime.
Notes from Ocrober 2002 meeting:
It might be desirable to shorten the storage duration of temporaries to allow reuse of them. The as-if rule allows some reuse, but such reuse requires analysis, including noting whether the addresses of such temporaries have been taken.
Notes from the August, 2011 meeting:
The CWG decided that further consideration of this issue would be deferred until someone produces a paper explaining the need for action and proposing specific changes.
See also issue 1634.