Thread: Is it ALWAYS safe to return temporary variables ?

There is nothing wrong with the above. You can return a copy of an object as long as that object has an implicit or explicit copy constructor

>but someone just pointed this out at a potential bug.
Who told you that, and what proof do they have?

Originally Posted by Mario F.

There is nothing wrong with the above. You can return a copy of an object as long as that object has an implicit or explicit copy constructor

Copy constructor and assignment operator both, as sometimes it can't use the copy constructor (e.g. if the variable already existed, it will use the assignment operator).

Anyhow, nobody can say what happens on all compilers, but all compilers *following C++ standards* allow this.

>but is it GAURANTEED to work no matter what compiler and what H/W.
For a conforming compiler, absolutely. Unfortunately, we can't make blanket claims about non-conforming compilers. However, these semantics have been in place since before C, so any compiler that fails to make that guarantee while claiming to implement C++ is severely broken.

There is one situation, and that is when the local object itself holds a reference to another local object and its copy constructor does not copy that object. In that case, the same caveats as with returning temporaries apply.

Originally Posted by Mario F.

There is nothing wrong with the above. You can return a copy of an object as long as that object has an implicit or explicit copy constructor

That's not necessarily true. The copy constructor (and assignment operator) need to provide the comment semantics, regardless of whether they are implicit (eg compiler generated) or explicit (eg programmer generated).

As CorndBee alluded, one case where this isn't necessarily true is if the class type contains a pointer or reference type. In practice, the implicitly generated constructor may not do this correctly (as it effectively does a bitwise copy of the value of pointers and references, which may not make sense for the class). If the programmer forgets to explicitly provide a copy constructor and/or assignment operator for the class in this case, returning an object of that type from a function (which logically invokes the copy constructor) or assigning the value to a variable (which logically invokes the assignment operator or copy constructor) can yield undefined or other spurious behaviours.

For example, this causes both a memory leak and undefined behaviour as main() returns.

Code:

#include <iostream>
class X
{
    int *x;
   
    public:
        X() : x (new int) {};
        ~X() {delete x;};
        void set(int y) {*x = y;};
        void print() const {std::cout << *x << '\n';};
}

int main()
{
     X a;
     X b = a;    // this invokes copy constructor

     //  Problem now  ....   a.x and b.x point at the same integer as the
     //    compiler generated copy constructor does a bitwise copy of pointers

     a.set(5);
     b.set(10);
     a.print();    // will print a value of 10, not 5
     b.print()     // will print a value of 10
     
     //   as main() returns destructors invoked.
     //    a.x will be deleted twice =>undefined behaviour
     //    the original value of b.x (as created by b's constructor) will not
     //      be deleted by X's destructor
   
}

The above ignores compiler optimisation. Things get a little more complicated, as compilers are allowed to -- but not required to -- eliminate some calls of constructors in some instances involving temporaries (and returning a value from a function is once such instance => the return value optimisation). Such things virtually guarantee that the code above will function differently between compilers and even compiler/optimiser settings for a particular compiler (even if we ignore the presence of undefined behaviour as main() returns).

>That's not necessarily true.
I think you missed this part of Mario's post:
>or explicit copy constructor

Originally Posted by swoopy

>That's not necessarily true.
I think you missed this part of Mario's post:
>or explicit copy constructor

No I did not. I just used an example with an implicitly generated copy constructor.

Having an explicit copy constructor is not the same thing as making that copy constructor behave correctly for all usage patterns. There is no way to force a programmer (other than embarrassment and other non-technical means) to write a copy constructor that does what the user of the class expects.

Having an explicit copy constructor is not the same thing as making that copy constructor behave correctly for all usage patterns.

I'm assuming that's what Mario meant.

The usage rules are provided by the class implementer and exposed through the interface. The user of the class has no other choice than to follow these rules, derive, or create his own implementation.

Of course, bugs in the implementation of the class will render it... useless for the most part. And needless to say that an explicit and conscious negation of a suitable copy constructor and assignment operator will not allow the example the OP provided. But that type of implementation, again, is exposed through the interface. The user must know how to interpret the class usage.

But all things equal, and that is what I believe the point of the OP was, there is nothing wrong or "bugable" in returning an object by value.

We could probably waste a few good forum pages discussing situations where this would not be possible. None of them though would negate the previous paragraph.

Originally Posted by swoopy

I'm assuming that's what Mario meant.

Absolutely.