What's the most reliable way to prohibit a copy constructor in C++?

Question

Sometimes it's necessary to prohibit a copy constructor in a C++ class so that class becomes "non-copyable". Of course, operator= should be prohibited at the same time.

So far I've seen two ways to do that. Way 1 is to declare the method private and give it no implementation:

class Class {
//useful stuff, then
private:
    Class( const Class& ); //not implemented anywhere
    void operator=( const Class& ); //not implemented anywhere
};

Way 2 is to declare the method private and give it "empty" implementation:

class Class {
//useful stuff, then
private:
    Class( const Class& ) {}
    void operator=( const Class& ) {}
};

IMO the first one is better - even if there's some unexpected reason that leads to the copy constructor being called from the same class member function there'll be a linker error later on. In the second case this scenario will be left unnoticed until the runtime.

Are there any serious drawbacks in the first method? What's a better way if any and why?

Falsify

boost.org/doc/libs/1_46_1/boost/noncopyable.hpp – Mauldon

Answer 1

The first method is how Boost solves it (source code), as far as I know, there's no drawbacks. In fact, the linker errors are the big advantage of that method. You want the errors to be at link time, not when your client is executing your code and it suddenly crashes.

In case you are using Boost, you can save yourself some typing. This does the same as your first example:

#include <boost/utility.hpp>

class Class : boost::noncopyable {
// Stuff here
}

Dagostino

While it might be "how Boost solves it", there's still a significant difference between solving it that way in a base class and doing it yourself in your own class in that the base-class approach is much more self-documenting, preventing someone carelessly adding it in the class later, thinking it was unimplemented by mistake. – Varick

That would still be a good scenario, as it allows you to catch that someone before they do real damage. Of course, you can't expect juniors to know this, but they shouldn't be making such changes without review anyway. – Dash

@Tony: I much prefer the boost alternative too (or another custom class when boost cannot be used). It is easier to understand, much more readable, and the error messages are a bit better. – Wetterhorn

Answer 2

The first one is better

Even better is C++0x 'delete' keyword:

class Class {
// useful stuff, then
public:
    Class(const Class&) = delete;
    void operator=(const Class&) = delete;
};

Syllogize

@sehe: with delete there is no reason to make it private. Indeed, having it appear in the public interface seems better, user-wise. – Wetterhorn

@Matthieu Use of delete in this context is C++11; if you have to target any older compilers, and even a lot of more recent ones, you can't use it. – Unclear

@James Kanze aren't C++0x and C++11 the same? At least WikiPedia says so: en.wikipedia.org/wiki/C++11 – Corsiglia

@FractalizeR: They are the same. C++0x was the "project" name. Now that the standard has been finalized, we know it should be published in 2011, thus the "new" standard should be C++11. – Wetterhorn

@Matthieu Then what @James talks about? I got him so that he meant that delete in this context is not in C++0x, but in C++11. – Corsiglia

@FractalizeR: I think he refers to the fact that the techic cannot be used to C++03, in which case you need make them private to prevent accidental use. – Wetterhorn

@FractalizeR C++11 is the name for what was informally known as C++0x. There is no real C++0x. C++11 replaces (or formally, will replace, since the full ISO process hasn't finished yet) C++03, which in turn replaced C++98. Most compilers in common use today support a subset of C++98 or C++03 (or a mixture of the two). Some also add features from earlier drafts of C++0x, which may or may not correspond to what was actually adopted in C++11. – Unclear

Answer 3

You can always inherit from boost::noncopyable.

Otherwise I've never seen a reason number 2 is better than number 1 as it will allow you to "copy construct" an object within friend or class methods even though it won't actually create a true copy of the object.

Frants

Answer 4

As other answers suggest something else, and doesn't really attempt to answer the question, so here is my attempt:

So which approach is better? It depends on how you define prohibit copy?

If you want to prevent others (only non-friend classes and functions) from copying while allowing friends and member-functions to copy, then second approach is the way to go.

If you want to prevent everyone (friends, non-friends, member-functions) from copying, then first approach is the only correct solution.

Note that the second approach does not prevent friends and member-functions from copying (that is, from calling the copy-functions). ¹

^{1. If you don't properly define them in the second case, then copy wouldn't work, as expected, but that is a different thing altogether. But the point is that second case doesn't prevent from calling the copy-functions. The compiler wouldn't generate any error message.}

Ashford

Answer 5

There is no drawback in your first approach, I has been using that to make "non-copyable" class ..

Isochronal

Answer 6

Personally I think you've answered your own question, and should use the first approach.

If you don't want it to be copyable at all, as you said it will throw a linker error. However if you use the second approach and you DO end up using the copy constructor by accident, it WILL compile and it WILL run; and you'll have absolutely no indication of where the inconsistency came from until you bust open a debugger. Or as sehe said, if you can use a modern compiler, use C++11's '= delete' notation.

Landon