Assigning to temporary (like 5 = 10 but for user-defined types)

Question

Hi, after doing some test-code for this link :
http://stackoverflow.com/questions/701313/is-it-safe-to-call-temporary-objects-methods
I found a rather strange feature of the c++ language, which I'm not sure how it works :

struct Test{
    int i;
    Test(int ii):i(ii){}
    Test& operator=(int ii){
     i = ii;
     return *this;
    }
    Test operator+(const Test& rhs){
     return Test(i + rhs.i);
    }
    void non_const_function(){
        i *= i;
    }
};

int main(){
        //code below gives errors, builtin types don't allow evil code
        //int i = 5+5 = 8;
        //int& iRef = 5+5;
        //int* iPtr = &(5+5);
        //5 = 10;

        Test x = Test(5) + Test(5) = 8;//assign to a temporary
        Test& xRef = Test(5) + Test(5);//reference to a temporary
        Test* xPtr = &(Test(5) + Test(5));//address of a temporary
        Test(5) = Test(10);//assign to a temporary
        Test(8).non_const_function();//call a non-const function
        return 0;
}

xRef and xPtr are both working pointers, with the expected values.
Of course I wouldn't write such code in a real project, but I'm still interested how / why this works.
The only info I found on google about this was that "if you create a reference to a temporary, the temporaries lifetime is linked to the lifetime of the reference"

Note :
-not all compilers are that forgiving, e.g. Metrowerks ARM (does it use GCC ?) only allows const reference to temporaries.
EDIT :
-increasing the warning to W4 in VC++ 2008 showed lots of errors - good to know.

EDIT 2:
Thank you all for the help. I'm back to work, fixing 100's of warnings.
CONCLUSION : use highest warning from start (I even found a REAL bug thanks to /G4)

Answer 1

The assignment operator is just a function with a funny name. If you can call a function on a temporary (which you can), then you can assign to a temporary, given a suitable operator=().

Answer 2

This kind of thing is ubiquitous in many object-oriented programming languages, especially those with object overloading.

If the first statement were written

Text x = Test(5).add(Test(5)).set(8);

where .add and .set return the lefthand Test instances with the expected values, would you still be confused?

To break this example down, you're creating a Test object with value 5, then adding another Test object with value 5 to it, and returning the first Test object, now with value 10. Then you're setting its value to 8, and assigning that object to x (well actually it's not assignment, again you're creating a Test object named x, then setting its value to the temporary's value).

Answer 3

Let's go line by line:

    Test x = Test(5) + Test(5) = 8;//assign to a temporary

There's no big deal here. Temporaries are still just normal objects, and thus the assignment operator works on them just as it would on anything else.

    Test& xRef = Test(5) + Test(5);//reference to a temporary

Like Metroworks, my GCC doesn't allow a non-const reference to a temporary.

    Test* xPtr = &(Test(5) + Test(5));//address of a temporary

In addition, GCC warns about taking the address of a temporary, for obvious reasons.

   Test(5) = Test(10);//assign to a temporary

Again, this is just assignment, which, as I explained above, is no big deal.

    Test(8).non_const_function();//call a non-const function

Temporary objects aren't constant. There's nothing stopping them from calling non-const functions.

Answer 4

My reading of your question tells me you are confused with the lifetime of temporaries more than anything else. I think it will help if you put a couple of couts as below:

struct Test{
    int i;
    Test(int ii):i(ii){ std::cout << "new object\n"; }
    Test& operator=(int ii){
        i = ii;
        return *this;
    }
    Test operator+(const Test& rhs){
        return Test(i + rhs.i);
    }
    void non_const_function(){
        i *= i;
    }
    ~Test() { std::cout << "deleting ...\n"; }
};

Now run, and you should be able to see what exactly is going on under the hoods. (Style Check:Not checking for self-assignment is not a good thing.)

It will also help if you refer the standard: It discusses something similar to what you have posted:

12.2 Temporary objects

4 There are two contexts in which temporaries are destroyed at a different point than the end of the fullexpression. The first context is when a default constructor is called to initialize an element of an array. If the constructor has one or more default arguments, the destruction of every temporary created in a default argument expression is sequenced before the construction of the next array element, if any.

5 The second context is when a reference is bound to a temporary. The temporary to which the reference is bound or the temporary that is the complete object of a subobject to which the reference is bound persists for the lifetime of the reference except as specified below. A temporary bound to a reference member in a constructor’s ctor-initializer (12.6.2) persists until the constructor exits. A temporary bound to a reference parameter in a function call (5.2.2) persists until the completion of the full-expression containing the call. A temporary bound to the returned value in a function return statement (6.6.3) persists until the function exits. A temporary bound to a reference in a new-initializer (5.3.4) persists until the completion of the full-expression containing the new-initializer.

 struct S { int mi; const std::pair<int,int>& mp; };
 S a { 1, {2,3} };
 S* p = new S{ 1, {2,3} }; // Creates dangling reference

[ Note: This may introduce a dangling reference, and implementations are encouraged to issue a warning in such a case. —end note ] The destruction of a temporary whose lifetime is not extended by being bound to a reference is sequenced before the destruction of every temporary which is constructed earlier in the same full-expression. If the lifetime of two or more temporaries to which references are bound ends at the same point, these temporaries are destroyed at that point in the reverse order of the completion of their construction. In addition, the destruction of temporaries bound to references shall take into account the ordering of destruction of objects with static, thread, or automatic storage duration (3.7.1, 3.7.2, 3.7.3); that is, if obj1 is an object with the same storage duration as the temporary and created before the temporary is created the temporary shall be destroyed before obj1 is destroyed; if obj2 is an object with the same storage duration as the temporary and created after the temporary is created the temporary shall be destroyed after obj2 is destroyed. Example:

 struct S {
    S();
    S(int);
    friend S operator+(const S&, const S&);
    ~S();
 };
 S obj1;
 const S& cr = S(16)+S(23);
 S obj2;

the expression C(16)+C(23) creates three temporaries. A first temporary T1 to hold the result of the expression C(16), a second temporary T2 to hold the result of the expression C(23), and a third temporary T3 to hold the result of the addition of these two expressions. The temporary T3 is then bound to the reference cr. It is unspecified whether T1 or T2 is created first. On an implementation where T1 is created before T2, it is guaranteed that T2 is destroyed before T1. The temporaries T1 and T2 are bound to the reference parameters of operator+; these temporaries are destroyed at the end of the full-expression containing the call to operator+. The temporary T3 bound to the reference cr is destroyed at the end of cr’s lifetime, that is, at the end of the program. In addition, the order in which T3 is destroyed takes into account the destruction order of other objects with static storage duration. That is, because obj1 is constructed before T3, and T3 is constructed before obj2, it is guaranteed that obj2 is destroyed before T3, and that T3 is destroyed before obj1.

Answer 5

Regarding the first case, assigning to a temporary, I recall from my Effective C++ that it is good practice to declare your operators like

const Test operator+(const Test&) const

This will make the objects behave like built-in types in that respect, at least.

Answer 6

Take a look at the GotW #4 which discusses the mechanics creating a user-defined class that most closely mirrors built-in arithmetic types. If you take his advice, your Test struct would look more like this:

struct Test{
    ...
    Test& operator+=( const Test& other ) {
        i += other.i;
        return *this;
    }
    ...
};

const Test operator+( const Test& lhs, const Test& rhs ) {
    Test ret( lhs );
    ret += rhs;
    return ret;
}

Now Test behaves much better in the addition situations (lines 1, 2, and 3 fail to compile). This is one of the rare instances where returning a const copy is actually useful,