8

The C++ standards do not specify the storage duration of temporary objects. This is the subject of CWG issue 1634.

According to the linked site, the status of this issue is "drafting", which means:

Drafting: Informal consensus has been reached in the working group and is described in rough terms in a Tentative Resolution, although precise wording for the change is not yet available.

However there is no explicit mention of a consensus/resolution for this particular issue and I was also not able to find it anywhere else on the committee's site.

I guess that the consensus is that lifetime-extended temporaries should have storage duration equal to that of the reference they are bound to, but it is less clear for non-lifetime-extended temporaries.

In particular it is not clear to me whether a temporary created in a statement at block-scope would have (automatic?) storage duration extending to the end of the block, like an automatic variable declared at the same point would have, or whether its storage duration ends with its (default) lifetime at the end of the full-expression. The issue description hints at the latter being the case.

Is the description supposed to contain the "Tentative Resolution" and if so did I interpret is correctly or if not, can I find the "Tentative Resolution" of this issue somewhere else?

In addition, do the major compilers currently follow this consensus, either in a documented manner or de-facto?

See also older questions:

Edit for clarification:

I am not asking about the lifetime of the temporary, that is well-specified in the standard. I am asking about the storage duration. For example:

#include<new>

struct A {
    operator A*() {
        return this;
    }

    int i = 0;

    // Some other stuff (and non-trivial destructor)
};

A* ptr1 = A();
A* ptr1_new = new(ptr1) A();

// Use new object through ptr1_new

A* ptr2 = A();

int main() {
    A* ptr2_new = new(ptr2) A();

    A* ptr3 = A();
    A* ptr3_new = new(ptr3) A();

    // Use new objects through ptr2_new and ptr3_new
}

The question is whether the standard (committee) intends these placement-news to be well-defined or undefined behavior. After having thought about it for a while, I suppose that probably the intention is that all of them are undefined behavior, but I wanted to get a clear answer.

Another aspect is that the standard often refers to "objects of static/automatic/thread/dynamic storage duration" and that temporaries are objects, but without specification on how to determine to which of these four classes they belong.

walnut
  • 21,629
  • 4
  • 23
  • 59
  • Perhaps you're confused by what "storage duration" means. Because it doesn't tell you the scope of the object's lifetime necessarily. The rules of temporaries and lifetime extension tell you how long the temporary object will continue to exist. – Nicol Bolas Oct 13 '19 at 20:04
  • @NicolBolas Yes I am aware that lifetime and storage duration are not the same. I am specifically asking about the storage duration, i.e. whether the memory can be reused after the objects lifetime ended. I have added a (hopefully) clarifying edit. Actually your answer in the first linked question made me look into this issue originally. – walnut Oct 13 '19 at 21:58
  • "*I am specifically asking about the storage duration, i.e. whether the memory can be reused after the objects lifetime ended*" But that's not what storage duration controls. You can reuse the memory of any object; indeed, the act of the object's memory being reused causes its lifetime to end. Now, for automatic storage duration objects, you do need to create an object of the proper type in them before their storage duration ends. But that doesn't prevent reuse of their storage. – Nicol Bolas Oct 13 '19 at 22:23
  • @NicolBolas ok, imprecise wording on my part. I mean whether the memory can be reused after the implicit (?) lifetime ended, e.g. after the full-expression if the temporary was not bound to a reference. See the code I added to the question. – walnut Oct 13 '19 at 22:26
  • The CWG issue explains the situation quite well, right? It's not meaningful to reason about defected sections in the standard :) – L. F. Oct 14 '19 at 10:20
  • 1
    @L.F. I would like to know whether there is any more (public available) information from the committee about the direction they intend to take to resolve the issue. The site I linked does not seem to fully contain that. But if that is all there is, then that would be an answer. Also I am interested in how the major compilers handle this currently. I assume they must make a determination, e.g. to whether they can reuse the same stack space for temporaries in different full-expressions of the same block, even if their addresses are taken. – walnut Oct 14 '19 at 10:55

0 Answers0