Question

I’ve written a simple linked list because a recent interview programming challenge showed me how rusty my C++ has gotten. On my list I declared a private copy constructor because I wanted to explicitly avoid making any copies (and of course, laziness). I ran in to some trouble when I wanted to return an object by value that owns one of my lists.

class Foo
{
   MyList<int> list;  // MyList has private copy constructor

   public:
      Foo() {};
};

class Bar
{
   public:
      Bar() {};

      Foo getFoo()
      {
         return Foo();
      }
};

I get a compiler error saying that MyList has a private copy constructor when I try to return a Foo object by value. Should Return-Value-Optimization negate the need for any copying? Am I required to write a copy constructor? I’d never heard of move constructors until I started looking for solutions to this problem, is that the best solution? If so, I’ll have to read up on them. If not, what is the preferred way to solve this problem?

Answer 1

The basic problem is that return by value might copy. The C++ implementation is not required by the standard to apply copy-elision where it does apply. That’s why the object still has to be copyable: so that the implementation’s decision when to use it doesn’t affect whether the code is well-formed.

Anyway, it doesn’t necessarily apply to every copy that the user might like it to. For example there is no elision of copy assignment.

I think your options are:

• implement a proper copy. If someone ends up with a slow program due to copying it then their profiler will tell them, you don’t have to make it your job to stop them if you don’t want to.
• implement a proper move, but no copy (C++11 only).
• change getFoo to take a Foo& (or maybe Foo*) parameter, and avoid a copy by somehow mutating their object. An efficient swap would come in handy for that. This is fairly pointless if getFoo really returns a default-constructed Foo as in your example, since the caller needs to construct a Foo before they call getFoo.
• return a dynamically-allocated Foo wrapped in a smart pointer: either auto_ptr or unique_ptr. Functions defined to create an object and transfer sole ownership to their caller should not return shared_ptr since it has no release() function.
• provide a copy constructor but make it blow up somehow (fail to link, abort, throw an exception) if it’s ever used. The problems with this are (1) it’s doomed to fail but the compiler says nothing, (2) you’re enforcing quality of implementation, so your class doesn’t work if someone deliberately disables RVO for whatever reason.

I may have missed some.