Returning Large Objects in Functions

Question

Compare the following two pieces of code, the first using a reference to a large object, and the second has the large object as the return value. The emphasis on a \"large o

Answer 1

A somewhat idiomatic solution would be:

std::auto_ptr<LargeObj> getObjData()
{
  std::auto_ptr<LargeObj> a(new LargeObj);
  a->fillWithData();
  return a;
}

int main()
{
  std::auto_ptr<LargeObj> a(getObjData());
}

Answer 2

The second approach is more idiomatic, and expressive. It is clear when reading the code that the function has no preconditions on the argument (it does not have an argument) and that it will actually create an object inside. The first approach is not so clear for the casual reader. The call implies that the object will be changed (pass by reference) but it is not so clear if there are any preconditions on the passed object.

About the copies. The code you posted is not using the assignment operator, but rather copy construction. The C++ defines the return value optimization that is implemented in all major compilers. If you are not sure you can run the following snippet in your compiler:

#include <iostream>
class X
{
public:
    X() { std::cout << "X::X()" << std::endl; }
    X( X const & ) { std::cout << "X::X( X const & )" << std::endl; }
    X& operator=( X const & ) { std::cout << "X::operator=(X const &)" << std::endl; }
};
X f() {
    X tmp;
    return tmp;
}
int main() {
    X x = f();
}

With g++ you will get a single line X::X(). The compiler reserves the space in the stack for the x object, then calls the function that constructs the tmp over x (in fact tmp is x. The operations inside f() are applied directly on x, being equivalent to your first code snippet (pass by reference).

If you were not using the copy constructor (had you written: X x; x = f();) then it would create both x and tmp and apply the assignment operator, yielding a three line output: X::X() / X::X() / X::operator=. So it could be a little less efficient in cases.

Answer 3

Depending on how large the object really is and how often the operation happens, don't get too bogged down in efficiency when it will have no discernible effect either way. Optimization at the expense of clean, readable code should only happen when it is determined to be necessary.

Answer 4

Use the second approach. It may seem that to be less efficient, but the C++ standard allows the copies to be evaded. This optimization is called Named Return Value Optimization and is implemented in most current compilers.

Answer 5

The chances are that some cycles will be wasted when you return by copy. Whether it's worth worrying about depends on how large the object really is, and how often you invoke this code.

But I'd like to point out that if LargeObj is a large and non-trivial class, then in any case its empty constructor should be initializing it to a known state:

LargeObj::LargeObj() :
 m_member1(),
 m_member2(),
 ...
{}

That wastes a few cycles too. Re-writing the code as

LargeObj::LargeObj()
{
  // (The body of fillWithData should ideally be re-written into
  // the initializer list...)
  fillWithData() ;
}

int main()
{
  LargeObj a ;
}

would probably be a win-win for you: you'd have the LargeObj instances getting initialized into known and useful states, and you'd have fewer wasted cycles.

If you don't always want to use fillWithData() in the constructor, you could pass a flag into the constructor as an argument.

UPDATE (from your edit & comment) : Semantically, if it's worthwhile to create a typedef for LargeObj -- i.e., to give it a name, rather than referencing it simply as typedef std::vector<HugeObj> -- then you're already on the road to giving it its own behavioral semantics. You could, for example, define it as

class LargeObj : public std::vector<HugeObj> {
    // constructor that fills the object with data
    LargeObj() ; 
    // ... other standard methods ...
};

Only you can determine if this is appropriate for your app. My point is that even though LargeObj is "mostly" a container, you can still give it class behavior if doing so works for your application.

Answer 6

The way to avoid any copying is to provide a special constructor. If you can re-write your code so it looks like:

LargeObj getObjData()
{
  return LargeObj( fillsomehow() );
}

If fillsomehow() returns the data (perhaps a "big string" then have a constructor that takes a "big string". If you have such a constructor, then the compiler will very likelt construct a single object and not make any copies at all to perform the return. Of course, whether this is userful in real life depends on your particular problem.