21

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?

Improve this question
1

6 Answers 6

Reset to default
27

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; };
Improve this answer
Sign up to request clarification or add additional context in comments.

7 Comments

@sehe: with delete there is no reason to make it private. Indeed, having it appear in the public interface seems better, user-wise.
@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.
@James Kanze aren't C++0x and C++11 the same? At least WikiPedia says so: en.wikipedia.org/wiki/C++11
@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.
@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.
|
16

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 }
Improve this answer

3 Comments

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.
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.
@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.
7

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.

Improve this answer

Comments

3

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

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.

Improve this answer

Comments

2

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

Improve this answer

Comments

1

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.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.