Effective C + + Item 6: If you do not want to use the compiler automatically generated functions, you should explicitly deny

Effective C + + Chapter 2. Construction/destructor/assignment operations (constructors, destructors, and assignment Operators) Item 6. If you don't want to use the compiler's auto-generated function, you should explicitly reject it (explicitly disallow the compiler-generated functions you does not want)

Real estate agents sell houses, and an intermediary software system naturally must have a class to describe a house for sale:

class Homeforsale {...};

Property developers think that every asset is unique, so making a copy of the Homeforsale object is a little unreasonable. Therefore, you should be happy to see that the Homeforsale object copy action ended in failure:

Homeforsale H1; Homeforsale H2; Homeforsale H3 (H1);              // attempt to copy H1-  -should not be compiled h1 = h2;                        // attempt to copy H2-  -nor should it be compiled

Preventing compilation of this type of code is not very intuitive. Usually if you do not want the class to support a particular function, simply do not declare the corresponding functions on the line. However, this policy has no effect on the copy constructor and the copy assignment operator, because Item 5 has indicated that if you attempt to invoke them without declaring them, the compiler declares them.

This has come to a dilemma. If you do not declare a copy constructor or copy assignment operator, the compiler may produce a copy for you, and your class supports copying. If you declare them, your class still supports copying. But the goal here is to stop copying!.

The key to the answer is that all compiler output functions are public. To prevent these functions from being created, you have to declare them yourself, but there is no need for you to declare them public. So you can Huschenming the copy constructor or copy assignment operation to private. By explicitly declaring a member function to prevent the compiler from secretly creating its own version, making these functions private allows you to successfully prevent people from invoking it.

In general, this practice is not absolutely safe, because the member function and the friend function can still call the private function. Unless you define them, if someone accidentally calls any one, you get a connection error (linkage error). The trick of declaring member functions private and deliberately not implementing them is so acceptable that it is used in the C + + iostream library to block copying behavior. This trick is also very simple to implement with Homeforsale:

class homeforsale{public:     ... Private :    ...    Homeforsale (const Homeforsale &);        // only declarations    operator= (const Homeforsale &);};

With the class definition above, when the client attempts to copy the Homeforsale object, the compiler will obstruct him. If you accidentally do that within the member function or the friend function, the turn-to-connector makes a complaint.

It is possible to transfer the connection-period errors to the compiler (and that is good, after all, the better it is to detect errors), as long as the copy constructor and copy assignment operations are Huschenming as private, but not in Homeforsale itself, It is in a base class designed specifically to prevent copying movements. This base class is very simple:

class uncopyable{protected:     uncopyable () {}             // allow derived object construction and destruction    ~ uncopyable () {}private:     uncopyable (const  uncopyable &);         // but stop copying     . operator= (const  uncopyable&);};

To prevent Homeforsale objects from being copied, the only thing we need to do is inherit uncopyable:

class Private  Uncopyable       //class no longer declares the copy constructor or copy assignment operator {    ...};

This can work because any (even member function or friend function) attempts to copy the Homeforsale object, the compiler tries to generate a copy constructor and a copy assignment operator, and as Item 12 says, the "compile Will attempt to invoke the corresponding sibling of its base class, and those calls will be rejected by the compiler because its base class copy function is private.

The implementation and use of the Uncopyable class is subtle, including the need not to inherit it publicly (see item 32 and Item 39), and the destructor for uncopyable not necessarily virtual (see item 7) and so on. Uncopyable does not contain data and therefore complies with the empty base class optimization qualification described in Item 39. But since it always plays the base class, using this technique can lead to multiple inheritance (because you might also inherit other classes, multiple inheritance See item 40), and multiple inheritance sometimes blocks the empty base class optimization (see Item 39 again ）。 You can often ignore these subtle points and use uncopyable just like the above, as it works exactly as advertised. You can also use the version provided by Boost (see Item 55), class named Noncopyable.

Please remember

• To dismiss a function that the compiler automatically (secretly) provides, the corresponding member function can be declared private and not implemented. Using a base class like uncopyable is also a practice.

Effective C + + Item 6: If you do not want to use the compiler automatically generated functions, you should explicitly deny