20

Is it true that temporary objects are stored in dynamic (heap) memory?

einpoklum
  • 118,144
  • 57
  • 340
  • 684
Mihran Hovsepyan
  • 10,810
  • 14
  • 61
  • 111

4 Answers4

11

The standard does not mandate any memory area (heap/stack) for them, but they are just like local variables "automatic storage", that is at the end of the expression (or longer when bound to a ref-to-const) they are destructed.

Most implementations will store them on the stack just like local variables.

edit:

As James Kanze pointed out: In the case the lifetime of a temporary is extended via a ref-to-const, its store location is on most implementations somewhat determined by the storage location of that reference. That is, in the case of the reference being in static storage, the temporary will be too (just confirmed on gcc). (although IMHO while this is still a temporary in the standards sense, it is arguable whether this is a temporary in the intuitive english sense of that word)

PlasmaHH
  • 15,673
  • 5
  • 44
  • 57
  • -1 and I'll explain why. The scope is not necessarily the end of the expression even when not bound to a const reference, but it can extend even further due to optimizations. See my answer. – Luchian Grigore Feb 02 '12 at 09:32
  • @LuchianGrigore: So in your example, the temporary will exist after the `foo();` returned? can you quote from the standard where this is allowed to happen? – PlasmaHH Feb 02 '12 at 09:37
  • @Luchian Grigore Here http://stackoverflow.com/questions/9018778/will-temporary-object-be-deleted-if-there-is-no-const-reference-to-it says that it should be the end of expression, isn't it? – Mihran Hovsepyan Feb 02 '12 at 09:38
  • @PlasmaHH yes - 12.2/2. Also, see this question http://stackoverflow.com/questions/8451212/passing-temporary-object-as-parameter-by-value-is-copy-constructor-called/8451249#8451249 – Luchian Grigore Feb 02 '12 at 09:40
  • @PlasmaHH And I didn't say that the variable exists after the function. I only said the lifetime can extend beyond the end of the expression, when passing a temporary as a parameter. – Luchian Grigore Feb 02 '12 at 09:41
  • @PlasmaHH in the case `foo( A() )`, the temporary can be built directly in the function's scope, and used in the function directly instead of creating a copy. – Luchian Grigore Feb 02 '12 at 09:42
  • @LuchianGrigore If it is wrong it means that the expression `int x = foo();` is ill-formed, because it is possible that temporary constructed by `foo()` is deleted before initialization of x => it is not wrong, because the expression above is not ill-formed. – Mihran Hovsepyan Feb 02 '12 at 09:43
  • @PlasmaHH and in the case of return, you could do `return A();` and the temporary not copied and destroyed, as return value optimization can occur. Look it up. – Luchian Grigore Feb 02 '12 at 09:43
  • @MihranHovsepyan I posted a link to the standard that backs up what I said. That should be enough. – Luchian Grigore Feb 02 '12 at 09:43
  • @LuchianGrigore: 12.2/2 is an example talking about possible ways where the temporary is stored, and optimizations that might make the temporary totally disappear. It nowehere talks about extension of the lifetime of the temporary. Eliding the copy is _not_ extending the lifetime of the temporary, it is eliding the temporary. Also note that this is just an example section, and thus not normative, you would need to quote normative text that tells where the lifetime of a temporary is allowed to be extended until after the evaluation of the function call expression – PlasmaHH Feb 02 '12 at 09:45
  • @PlasmaHH if we're going to be anal (haha) about it, the standard doesn't say whether any temporary is on the stack or heap or whatever. – Luchian Grigore Feb 02 '12 at 09:47
  • @PlasmaHH But I do see your point. You're saying that if this optimization happens, it's no longer called a temporary. I agree and removed the downvote. However, I still think I make a good point. – Luchian Grigore Feb 02 '12 at 09:48
  • 2
    There are a few cases where it almost certainly isn't on the stack. Consider something like `static MyType const& x = MyType();`. In this case (and it's the only one I can think of), the temporary will probably be in the same space as static data. – James Kanze Feb 02 '12 at 09:54
  • @JamesKanze: Indeed, I just checked on gcc and it is in static. So maybe it is better to say that in the case a ref-to-const extends the lifetime, the storage location is somewhat determined by that ref – PlasmaHH Feb 02 '12 at 10:07
  • @plasma thats not enough. see below. – Johannes Schaub - litb Feb 02 '12 at 10:12
7

It depends on their lifetime. Temporaries you create inside of a function that you dont bind to a local static reference to lengthen their lifetime will most likely be created on the stack. Temporaries you bind to local static references will most likely be stored in the .data section of your program binary. Same holds for temporaries you bind to nonlocal references. Temporaries that are created during initialization of a nonlocal variable other that the one bound to by a reference should be on the stack of the function that produces the value of that nonlocal variable.

Exception objects that represent the thrown object during unwinding are temporaries too. Those usually reside on the heap.

Johannes Schaub - litb
  • 496,577
  • 130
  • 894
  • 1,212
  • Should be noted that my answer ignores the presence of thread local variables. someone experienced with that should speak up and clarify. – Johannes Schaub - litb Feb 02 '12 at 10:10
  • Indeed, while the OP probably did not have them in mind, exceptions are temporaries too. As well as the intializer lists in C++11. As for thread local variables, at least on x86_64/linux they will be stored in a special memory segment accessed with the help of the gs segment register, which is set differntly for each thread. – PlasmaHH Feb 02 '12 at 10:26
  • Are exception objects temporaries? Or something else entirely. (In §3.7, the standard lists four "storage durations": static, thread, automatic and dynamic. I've often wondered about this: temporaries clearly have a different duration, as do exception objects.) – James Kanze Feb 02 '12 at 11:10
  • @James it is not unreasonable to allocate the storage of full-expression temporaries on the stack for the lifetime of the surrounding block, even if the actual lifetime of the temporary is potentially substantially shorter. It's a simple model to implement and is allowed by the C++ spec. The example at the end of 12.2p5 talks about temporaries that have static storage duration. Unfortunately the static storage duration is sometimes used in the spec for things where it doesn't intend to match temporaries (like in the definition of "reference constant expression"). – Johannes Schaub - litb Feb 02 '12 at 21:18
  • The committee replied to your defect report that they see currently no action as nothing in the spec appeared to cause problems when temporaries have static or automatic storage duration (presumably because any use of "XXX storage duration" mentioned "variable", which does not interfere with temporaries because temporaries are not variables). But the definiton of reference and address constant expression refer to "objects of static storage duration", which *do* match temporaries. – Johannes Schaub - litb Feb 02 '12 at 21:20
4

This is highly implementation dependent, but they probably reside in automatic storage.

Note that the scope can be counter-intuitive, because of optimizations.

The following:

class A
{
//...
};

//....

A foo()
{
   A a;
   return a;
}

Here, the object a doesn't necessarily reside only inside the function's scope, but RVO can occur.

Also, when passing by value a temporary object, it might not get destructed immediately.

void foo(A a);
//...

foo( A() );

Here, a temporary is not necessarily only alive in that line, but can be constructed directly inside the method's argument stack.

Luchian Grigore
  • 253,575
  • 64
  • 457
  • 625
0

Most (if not all) implementations store them on the stack (i.e. automatic storage), although I don't think the standard mandates anywhere. It's certainly easier to do it like that, as the compiler has to guarantee the temporary variable's life time, and it is possible that said lifetime will encompass a recursive call of the same function, creating another instance of the temporary variable.

Tom Tanner
  • 9,244
  • 3
  • 33
  • 61