CODEWITHSUNDEEP
c++
swongu
swongu

Reputation: 2299

Returning Large Objects in Functions

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 object" refers to the fact that repeated copies of the object, unnecessarily, is wasted cycles.

Using a reference to a large object:

void getObjData( LargeObj& a )
{
  a.reset() ;
  a.fillWithData() ;
}

int main()
{
  LargeObj a ;
  getObjData( a ) ;
}

Using the large object as a return value:

LargeObj getObjData()
{
  LargeObj a ;
  a.fillWithData() ;
  return a ;
}

int main()
{
  LargeObj a = getObjData() ;
}

The first snippet of code does not require copying the large object.

In the second snippet, the object is created inside the function, and so in general, a copy is needed when returning the object. In this case, however, in main() the object is being declared. Will the compiler first create a default-constructed object, then copy the object returned by getObjData(), or will it be as efficient as the first snippet?

I think the second snippet is easier to read but I am afraid it is less efficient.

Edit: Typically, I am thinking of cases LargeObj to be generic container classes that, for the sake of argument, contains thousands of objects inside of them. For example,

typedef std::vector<HugeObj> LargeObj ;

so directly modifying/adding methods to LargeObj isn't a directly accessible solution.

Upvotes: 50

Views: 12123

Answers (9)

Dan Breslau
Dan Breslau

Reputation: 11522

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.

Upvotes: 0

rjnilsson
rjnilsson

Reputation: 2343

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

Upvotes: 2

John Dibling
John Dibling

Reputation: 101456

Your first snippet is especially useful when you do things like have getObjData() implemented in one DLL, call it from another DLL, and the two DLLs are implemented in different languages or different versions of the compiler for the same language. The reason is because when they are compiled in different compilers they often use different heaps. You must allocate and deallocate memory from within the same heap, else you will corrupt memory. </windows>

But if you don't do something like that, I would normally simply return a pointer (or smart pointer) to memory your function allocates:

LargeObj* getObjData()
{
  LargeObj* ret = new LargeObj;
  ret->fillWithData() ;
  return ret;
}

...unless I have a specific reason not to.

Upvotes: -1

David Rodr&#237;guez - dribeas
David Rodr&#237;guez - dribeas

Reputation: 208323

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.

Upvotes: 56

Simon Broadhead
Simon Broadhead

Reputation: 3483

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.

Upvotes: 0

anon
anon

Reputation:

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.

Upvotes: 2

Dima
Dima

Reputation: 39389

Alternatively, you can avoid this issue all together by letting the object get its own data, i. e. by making getObjData() a member function of LargeObj. Depending on what you are actually doing, this may be a good way to go.

Upvotes: 0

avakar
avakar

Reputation: 32635

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.

Upvotes: 15

KenE
KenE

Reputation: 1805

Yes in the second case it will make a copy of the object, possibly twice - once to return the value from the function, and again to assign it to the local copy in main. Some compilers will optimize out the second copy, but in general you can assume at least one copy will happen.

However, you could still use the second approach for clarity even if the data in the object is large without sacrificing performance with the proper use of smart pointers. Check out the suite of smart pointer classes in boost. This way the internal data is only allocated once and never copied, even when the outer object is.

Upvotes: 3

Related Questions