Re: destruction of already destructed pointer variable when copying an object - abort error
Goran <goran.pusic@gmail.com> wrote:
1. understand "the rule of three" (http://en.wikipedia.org/wiki/
Rule_of_three_%28C%2B%2B_programming%29)
Minor nitpick, but I think it's a bit incorrect to say that
"if a class defines one of the following it should probably explicitly
*define* all three" (emphasis mine).
In many cases it's sufficient to *declare* (rather than define) the
copy constructor and assignment operator (and declare them private), if
your class is such that it requires a user-defined destructor. Often this
is a much easier and less laborious way of adding the safety measure
without having to actually go through the trouble of fully implementing
copying (especially since in many cases there's no clear "best" approach
at copying an object; should it use deep-copying, lazy copying, or just
reference counting, or perhaps something else completely?)
2. class FO : public boost::noncopyable { ...
Is there any other advantage of boost:noncopyable other than that it
saves you from writing two lines of code in the private section of the
class? (And no, "it gives a better error message" is not a good enough
argument for requiring Boost to be installed in the system. Anybody who
is even half-competent at C++ will understand what it means if the copy
constructor or assignment operator of a class is inaccessible because it
has been declared private.)