Creating and returning a big object from a function [duplicate]

Question

Imagine such situation that I have a function like this:

Object f()
{
    Object obj;
    return obj;
}

Where sizeof(Object) is a big value.

And then I make a call of this function:

Object object = f();  

Do i understand correctly that first Object will be created on a stack (in the function) and then will be copied to object variable?

If so, is it reasonably to create an object in the function on a heap and to return a pointer to it instead of a copy ?

But i mean that the object must be created in the f() function - not passed by a pointer or a reference to this function and initialized.

EDIT

I don't mean that f is a very simple function. It can have a really complex routine of object initialization depending on some context. Will the compiler still optimize it as well?

Answer 1

For that specific case, you can take advantage of the fact that compilers nowadays are smart enough to optimize for it. The optimization is called named return value optimization (NRVO), so it's okay to return "big" objects like that. The compiler can see such opportunities (especially in something as simple as your code snippet) and generate the binary so that no copies are made.

You can also return unnamed temporaries:

Object f()
{
    return Object();
}

This invokes (unnamed) return value optimization (RVO) on just about all modern C++ compilers. In fact, Visual C++ implements this particular optimization even if all optimizations are turned off.

These kinds of optimizations are specifically allowed by the C++ standard:

ISO 14882:2003 C++ Standard, §12.8 para. 15: Copying Class Objects

When certain criteria are met, an implementation is allowed to omit the copy construction of a class object, even if the copy constructor and/or destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy operation as simply two different ways of referring to the same object, and the destruction of that object occurs later of the times when the two objects would have been destroyed without the optimization. This elison of copy operations is permitted in the following circumstances (which may be combined to eliminate multiple copies):

• in a return statement in a function with a class terturn type, when the expression is the name of a non-volatile automatic object with the same cv-unqualified type as the function return type, the copy operation can be omitted by constructing the automatic object directly into the function's return value
• when a temporary class object that has not been bound to a reference would be copied to a class object with the same cv-unqualitied type, the copy operation can be omitted by constructing the temporary object directly into the target of the omitted copy.

Generally, the compiler will always try to implement NRVO and/or RVO, although it may fail to do so in certain circumstances, like multiple return paths. Nevertheless, it's a very useful optimization, and you shouldn't be afraid to use it.

If in doubt, you can always test your compiler by inserting "debugging statements" and see for yourself:

class Foo
{
public:
    Foo()                      { ::printf("default constructor\n"); }
    // "Rule of 3" for copyable objects
    ~Foo()                     { ::printf("destructor\n");          }
    Foo(const Foo&)            { ::printf("copy constructor\n");    }
    Foo& operator=(const Foo&) { ::printf("copy assignment\n");     } 
};

Foo getFoo()
{
    return Foo();
}

int main()
{
    Foo f = getFoo();
}

If the returned object isn't meant to be copyable, or (N)RVO fails (which is probably not likely to happen), then you can try returning a proxy object:

struct ObjectProxy
{
private:
    ObjectProxy() {}
    friend class Object;    // Allow Object class to grab the resource.
    friend ObjectProxy f(); // Only f() can create instances of this class.
};

class Object
{
public:
    Object() { ::printf("default constructor\n"); }
    ~Object() { ::printf("destructor\n"); }
    // copy functions undefined to prevent copies
    Object(const Object&);
    Object& operator=(const Object&);
    // but we can accept a proxy
    Object(const ObjectProxy&)
    {
        ::printf("proxy constructor\n");
        // Grab resource from the ObjectProxy.
    }
};

ObjectProxy f()
{
    // Acquire large/complex resource like files
    // and store a reference to it in ObjectProxy.
    return ObjectProxy();
}

int main()
{
     Object o = f();
}

Of course, this isn't exactly obvious so proper documentation would be needed (at least a comment about it).

You can also return a smart pointer of some kind (like std::auto_ptr or boost::shared_ptr or something similar) to an object allocated on the free-store. This is needed if you need to return instances of derived types:

class Base {};
class Derived : public Base {};

// or boost::shared_ptr or any other smart pointer
std::auto_ptr<Base> f()
{
    return std::auto_ptr<Base>(new Derived);
}

Answer 2

In theory what you describe is what should happen. Anyway compilers are often able to optimize it in a way, that the caller's Object is used: f will directly write on caller's object and return null.

This is called Return Value Optimization (or RVO)