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