Question: In our company's coding standard, we have been told to "be aware of the ways (accidental) copying can be prevented".

I am not really sure what this means, but assume that they mean we should stop classes from being copied if this is not required.

What I can think of is as follows:

1. Make the copy constructor of a class private.
2. Make the assignment operator (operator=) of a class private.
3. Make the constructor of a class explicit (to stop classes from being created using incorrect variables).
4. For all classes that carry out memory allocation and where copying is required, make sure that the copy constructor and assignment operator carry out deep copying rather than shallow copying.

Am I on the right track? Is there anything I might have missed out?

Answer: 
Yes, making assignment operator and copy constructor private will prevent you from creating any copy of object using standart methods (but if you really need a copy of an object you can implement, for example, Copy() method, which will perform deep copy).

Take a look on [boost::noncopyable](http://www.boost.org/doc/libs/1_39_0/boost/noncopyable.hpp).

**Update** (re to Tal Pressman):

> 
> ...you should be aware of these things and watch out that you don't accidentally copy objects you're not supposed to.
> 
> 
> 

Well, I presume, that any *accidental* copy will be performed using either assignment operator or copy constructor. So making them private actually makes sense: if object copying is costly operation, then copying must be explicit: other developer can unintentionally indirectly call copy op and compiler will inform him, that this is forbidden.
Your list looks great from the point of view of avoiding errors, e.g. deleting the same area of memory more than once due to shared pointers from implicit copying of objects.

I hope this is also relevant; from the statement "be aware of the ways (accidental) copying can be prevented" you might take this to mean 'be aware of unintentional unnecessary copying'. This would mean circumstances which might affect performance. In a very simple example your coding conventions might mean you should prefer:

```
std::string text1( "some text" );

```

over:

```
std::string text1 = "some text";

```

The second case would result in a temporary string being created to hold "some text" before the assignment operator is invoked (a form of copying) to populate text1 with "some text". Obviously this is a trivial example and good practice would dictate that you should use the constructor initialisation (first example) where ever possible.