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

This question already has answers here: Avoiding copy of objects with the "return" statement (7 answers) Closed 6 years ago.

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 initiali开发者_C百科zation depending on some context. Will the compiler still optimize it as well?

---

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);
}

---

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)

---

The compiler will optimize it.

Except in some situations, such as:

std::string f(bool cond = false)
{
  std::string first("first");
  std::string second("second");
  // the function may return one of two named objects
  // depending on its argument. RVO might not be applied
  if(cond)
    return first;
  else
    return second;
}

Of course there can be some old compilers, which can call copy constructor. But you shouldn't worry about it with modern compilers.

---

Whether the compiler can apply RVO depends on the actual code involved. A general guideline is to create the returned value as late as possible. For example:

std::string no_rvo(bool b) {
  std::string t = "true", f = "fals";

  f += t[3];  // Imagine a "sufficiently smart compiler" couldn't delay initialization
  // for some reason, such not noticing only one object is required depending on some
  // condition.

  //return (b ? t : f);  // or more verbosely:
  if (b) {
    return t;
  }
  return f;
}

std::string probably_rvo(bool b) {
  // Delay creation until the last possible moment; RVO still applies even though
  // this is superficially similar to no_rvo.
  if (b) {
    return "true";
  }
  return "false";
}

With C++0x, the compiler is free to make even more assumptions, principally by being able to use move semantics. How those work is a 'nother can of worms, but move semantics are being designed so that they can apply to the exact code above. This helps most dramatically in the no_rvo case, but it provides guaranteed semantics in both cases, as a move operation (if possible) is preferred over a copy operation, while RVO is completely optional and not easy to check.

---

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

Yes obj is created on the stack but when you return a process called return value optimisation or RVO can prevent the unnecessary copy.

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 ?

Yes it is reasonable to create an object on the heap and return a pointer to it as long as you clearly document the client is responsible for cleaning up the memory.

However, it's better than reasonable to return a smart pointer such as shared_ptr<Object> which alleviates the client from having to remember to explicitly free the memory.

---

If your function f is a factory method, it is better to return a pointer, or an initialized smart pointer object such as auto_ptr.

auto_ptr<Object> f()
{
     return auto_ptr<Object>(new Object);
}

To use:

{    
    auto_ptr<Object> myObjPtr = f();
    //use myObjPtr . . . 
} // the new Object is deleted when myObjPtr goes out of scope

---

I don't know why nobody pointed out the obvious solution yet. Just pass the output object by reference:

void f(Object& result) {
  result.do_something();
  result.fill_with_values(/* */);
};

This way:

• you avoid the copy for sure.

• you avoid using the heap.

• you avoid leaving the calling code with the responsibility of freeing the dynamically-allocated object (although shared_ptr or unique_ptr would do that too).

Another alternative is to make the function a member of Object, but that might not be appropriate, depending on what f()'s contract is.