Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I do not have the book “Practical C++ Programming” by Steve Oualline but I was reading his Ten Commandments for C++ programmers at http://code.rkevin.com/2010/07/the-ten-commandments-for-c-programmers/ and I was wondering if the first has been correctly transcribed? For reference the transcription is:

"1. Thou shalt not rely on the compiler default methods for construction, destruction, copy construction, or assignment for any but the simplest of classes. Thou shalt forget these “big four” methods for any nontrivial class."

He seems to be advocating manually defining copy construction and copy assignment. Is that a correct interpretation of his first commandment?

Edit: Although at present I am leaving Adrian's answer as the accepted one I would like anyone who views this question to read Jerry's. I did specifically ask whether the above text is accurately transcribed and not about its merit (which is probably a more interesting discussion). But Jerry does make some good points about its merit (or lack thereof) which are similar to my opinions of it. I just wanted to make sure I had the quote right before I constructed a thorough argument of why I disagree with it.

share|improve this question
Now you have: dsi.fceia.unr.edu.ar/downloads/informatica/info_II/c++.../… (2nd link in google, must be legal, right?) –  mlvljr Aug 6 '13 at 20:39
@Jerry: This is the right answer. Can you please make it one? Otherwise we are stuck with only one wrong answer. –  kevin cline Aug 7 '13 at 19:02

2 Answers 2

up vote 7 down vote accepted

For "any nontrivial" class I am sure that is exactly what he is suggesting - and it would certainly be good practice to write an explicit copy constructor or overloaded assignment for such a non-trivial class.

share|improve this answer
Disagree with "good practice". A non-trivial class very often is a non-trivial composition of trivial classes, and therefore has perfectly well-defined implicit methods. It turns out that the C++ rules make the class as exception-safe as its members. Trying to achieve the same safety inside an explicitly defined assignment operator, without relying on members, is hard to impossible. –  MSalters Aug 8 '13 at 12:27

It looks to me like it's probably accurately transcribed. Unfortunately, the advice is mostly out of date (to the extent it was ever good at all). The book in question was written in 1995 and updated in 1997. A lot has happened in the 15+ years since then that renders this advice obsolete.

The advice is based on the notion of a non-trivial class implementing "remote ownership" -- i.e., containing one or more pointers to data it owns that will be allocated on the free store. Obvious examples are things like std::string and std::vector, each of which normally allocates a block of memory to hold the data in the container (and the string or vector object itself contains only the pointer and a little bookkeeping data, such as the size of the allocated block and the number of items in that block that are currently in use).

The reason I say that's out of date is that in most cases, you should not be using raw pointers for remote ownership at all. Instead, you should typically use a smart pointer (e.g., unique_ptr or shared_ptr) to manage the remote ownership. That smart pointer should implement the remote ownership "policy" (copying, assignment, destruction) of the data it owns.

Then the non-trivial class will simply aggregate an instance (or more than one, depending) to manage its remote data. In the process, it gets the correct ownership policy implemented by those smart pointers. As a result, it usually won't need to implement any of the above at all.

That typically leaves only construction to be handled by the non-trivial class. Even that will typically just "distribute" data out to the base class and/or aggregated objects, so the body of the ctor is often empty:

class foo {
    std::unique_ptr<T> data;
    foo(T const &input) : data(make_unique(input)) : {}

Bottom line: a non-trivial class should present a logical view of an abstraction. It should deal almost exclusively with the logic of the abstraction it represents. It should rarely (if ever) directly deal directly with low-level, language-oriented issues such as allocation, deletion, and copying of memory needed to represent the abstraction it represents.

Those issues should nearly always be dealt with by lower-level classes also designed to represent an abstraction -- but in this case, a fairly simple abstraction of "remotely owned data", that knows how to handle things like copying, assigning, and destroying the data it owns, with little or no help from the class that owns it (e.g., the owning class passing some function arguments to tell how to destroy the owned data). At least in many (most?) typical cases, one of the pointer classes in the standard library (such as the aforementioned unique_ptr or shared_ptr) will be entirely adequate to this task.

As a result, you should rarely need to define your own copy constructor, copy assignment or destructor. These issues should typically be handled by lower-level classes devoted to providing remote ownership.

References and further reading:

  1. http://flamingdangerzone.com/cxx11/2012/08/15/rule-of-zero.html
  2. http://herbsutter.com/2013/05/29/gotw-89-solution-smart-pointers/
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.