I do not have the book “Practical C++ Programming” by Steve Oualline but I was reading his Ten Commandments for C++ programmers at The Ten Commandments for C++ Programmers and I was wondering if the first has been correctly transcribed? For reference the transcription is:
- 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.
3
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.
2
I think this is probably inaccurately transcribed in one respect. The sentence: “Thou shalt forget these “big four” methods for any nontrivial class.” is probably intended to read: “Thou shalt not forget these “big four” methods for any nontrivial class.”
Other than that, it looks to me like it’s probably accurately transcribed. Unfortunately, the advice is mostly out of date. 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 probably be allocated on the free store, but somewhere outside the object itself in any case). 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;
public:
foo(T const &input) : data(std::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. There is, however, still a fair argument to be made that for non-trivial classes, these should still be defined (at least in most cases) but defined as = default; in most cases.
References and further reading:
- https://web.archive.org/web/20151006051620/http://flamingdangerzone.com/cxx11/rule-of-zero/
- http://herbsutter.com/2013/05/29/gotw-89-solution-smart-pointers/