5

Possible Duplicate:
Guaranteed lifetime of temporary in C++?
Lifetime of temporaries

I have a quick question regarding the lifespan of a temporary object, when returned from an overloaded operator+ method. For example, if the expression...

a = b + c + d + e

...is evaluated by overloaded operator+ methods which return temporary objects, is the scope of the temporary returned by the sub-expression b + c that of the entire expression?

As g++ appears to hold onto all temporaries whilst the entire expression is within scope, references to these values may be held for delayed evaluation during the a = assignment.

Could somebody please confirm whether or not this behaviour is guaranteed for all C++ implementations?

Community
  • 1
  • 1
Taliadon
  • 438
  • 4
  • 11

3 Answers3

6

Yes, in the usual case: "Temporary objects are destroyed as the last step in evaluating the full-expression (1.9) that (lexically) contains the point where they were created." (§12.2/3).

There a couple of exceptions to this, but they don't apply here.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
  • Thanks Jerry; just the answer I was hoping for. In order to avoid getting ahead of myself, I won't worry about the odd exception at this particular point in time. Again, thanks for the help. – Taliadon Jul 10 '11 at 04:20
1

Yes, a temporary object is only destroyed after all evaluations in the full-expression. (A statement is the most common kind of full-expression. Certain uses of references can make a temporary object last longer.)

aschepler
  • 70,891
  • 9
  • 107
  • 161
0

This may be a bit off topic, but there are differences between G++ (MinGW 4.4.1) and MSCV++ 10 in the scope of returned temporary variables created on the stack.

I just created an object, called say myObj and class members are coordinates, vectors, whatever ...

The class has a default constructor, another constructor that initializes class members, a copy constructor, and overloaded +, += and = operators.

myObj & myObj::operator+(myObj & mO)
{
    myObj retO = myObj(mO); // using a non-default constructor defined
    retO += *this;          // Uses the other overloaded operator defined.
    return retO;
}

The + operator allocates a myObj object on the stack (NOT using new) and adds the objects *this and mO (via retO) and assigns them to the retO object created on the stack.

G++ allows you to call:

myObj2 = myObj1 + myObj2;

However, Visual Studio 10.0 destroys retO that was created on the stack immediately after the overloaded operator member function exits (verified using static member increment and decrement with output inside all constructors and the destructor).

I do not know how the standard defines this behavior. Oddly enough, MinGW gives a compiler warning whereas MSVC++ 10 does not.

Of course the problem with creating a new myObj object with the new keyword is memory leakage as the above construct does not keep a reference to the new myObj instantiation, which is allocated to myObj2.

Regards,

Navid

user998198
  • 133
  • 7
  • g++ is right to issue a compiler warning. The `myObj::operator+(myObj&)` member function, which really should be declared as `myObj::operator+(const myObj&) const`, is returning a reference to a temporary object. Per the standard, the code you posted would obtain a reference to the local `myObj` object `ret0`, destroy `ret0` when exiting the block (returning), and return the reference. But notice that the reference is to a destructed object *and* it is a reference to an object allocated on the stack. Very bad. – Daniel Trebbien Oct 16 '11 at 22:32
  • 1
    I totally agree - as I said a bit off topic as not a simple type but an object reference is returned. But the temp references' persistence differ to address the questions about compiler differences. The solution is of course to return a new object and use the overloaded += operator for assignments to the same object and to use the overloaded + operator only for assignments to a new object in order to avoid memory leaks. I still can't figure out why I get no warning from MSCV++. Already looked through all options in the IDE ... – user998198 Oct 18 '11 at 04:48