0

I've seen in several places the advice to either define your own assignment operator/copy constructor, or to block the default ones by declaring them private.

However, the only danger I've been able to find was the problem of creating copies of pointers that could be dangling pointers later.

In modern C++ pointers are rare, and most classes just use smart pointers (e.g. from boost or from the std library in C++11). Is it still necessary to declare the assignment operator and the copy constructor for classes that have no raw pointers?

And mainly: What are the dangers of not doing that? What kind of unexpected behavior can occur?

Schiavini
  • 2,869
  • 2
  • 23
  • 49
  • The only time you need to define your own assignment operator or copy constructor is at the same time you define a destructor. This is the [Rule of Three](http://stackoverflow.com/questions/4172722/what-is-the-rule-of-three). But if you're only using resource managing classes and not creating one, there should be no need to do anything special, because the implicitly generated special functions for your class will use the specifically written ones from the resource managing classes, which should just do the Right Thing. – GManNickG Nov 02 '12 at 09:00

3 Answers3

1

Not it's not necessary to hide those operators. std::unique_ptr already is noncopyable(you can only move it). And other kinds - std::shared_ptr will increment internal ref count, std::weak_ptr will do nothing since it has lock method. You can read more here (Boost libs)

Denis Ermolin
  • 5,530
  • 6
  • 27
  • 44
0

This is explained in the question What is The Rule of Three?

Also there is a very good explanation on the following website:

Can I trust the Compiler-Generated Copy Constructor and Assignment Operator?

Compiler-generated code is your best friend, provided that you adhere to good style OO practices and know the rules. As explained in part I, the compiler- generated copy constructor and assignment operator perform member-wise copying of user-declared data members. By replacing low-level datatypes -- raw pointers and char arrays for instance -- with their high-level Standard Library counterparts std::tr1::shared_ptr and std::string, not only are you eliminating the onerous bugs associated with manual resource management, you’re also guaranteeing that the compiler-generated copy constructor and assignment operator will do the right thing.

Community
  • 1
  • 1
Schiavini
  • 2,869
  • 2
  • 23
  • 49
-1

The danger with not defining your own assignment operator/copy/move constructor is the possibility of unexpected behavior. These operations are very easily invoked without you being aware of that, causing the unexpected behavior. Declaring them as private will result in compilation error on such occasions.

Also note that not everywhere smart pointers are used. There are more restricted environments (such as kernel, embedded etc.) that generally won't have STL or boost.

SomeWittyUsername
  • 18,025
  • 3
  • 42
  • 85