C.hierclass: Designing classes in a hierarchy:

C.126: An abstract class typically doesn’t need a user-written constructor

• Reason An abstract class typically does not have any data for a constructor to initialize.Example

class Shape {
public:
   // no user-written constructor needed in abstract base class
   virtual Point center() const = 0;    // pure virtual
   virtual void move(Point to) = 0;
   // ... more pure virtual functions...
   virtual ~Shape() {}                 // destructor
};

class Circle : public Shape {
public:
   Circle(Point p, int rad);           // constructor in derived class
   Point center() const override { return x; }
};

• Exception
  -- A base class constructor that does work, such as registering an object somewhere, might need a constructor.
  -- In extremely rare cases, you might find it reasonable for an abstract class to have a bit of data shared by all derived classes (e.g., use statistics data, debug information, etc.); such classes tend to have constructors. But be warned: Such
  classes also tend to be prone to requiring virtual inheritance.
• Enforcement
  Flag abstract classes with constructors.

C.127: A class with a virtual function should have a virtual or protected destructor

Reason

A class with a virtual function is usually (and in general) used via a pointer to base. Usually, the last user has to call delete on a pointer to base, often via a smart pointer to base, so the destructor should be public and virtual. Less commonly, if deletion through a pointer to base is not intended to be supported, the destructor should be protected and non-virtual; see C.35.

Example, bad

struct B {
    virtual int f() = 0;
    // ... no user-written destructor, defaults to public non-virtual ...
};

// bad: derived from a class without a virtual destructor
struct D : B {
    string s {"default"};
    // ...
};

void use()
{
    unique_ptr<B> p = make_unique<D>();
    // ...
} // undefined behavior, might call B::~B only and leak the string

Note

There are people who don’t follow this rule because they plan to use a class only through a shared_ptr: std::shared_ptr<B> p = std::make_shared<D>(args); Here, the shared pointer will take care of deletion, so no leak will occur from an inappropriate delete of the base. People who do this consistently can get a false positive, but the rule is important – what if one was allocated using make_unique? It’s not safe unless the author of B ensures that it can never be misused, such as by making all constructors private and providing a factory function to enforce the allocation with make_shared.

Enforcement

• A class with any virtual functions should have a destructor that is either public and virtual or else protected and non-virtual.
• Flag delete of a class with a virtual function but no virtual destructor.

这个是经常看到的很重要的一条，通常的case就是base class 的dtor要public and virtual,或者protected and non-virtual(少见）

C.128: Virtual functions should specify exactly one of virtual, override, or final

Reason

Readability. Detection of mistakes. Writing explicit virtual, override, or final is self-documenting and enables the compiler to catch mismatch of types and/or names between base and derived classes. However, writing more than one of these three is both redundant and a potential source of errors.

It’s simple and clear:

• virtual means exactly and only “this is a new virtual function.”
• override means exactly and only “this is a non-final overrider.”
• final means exactly and only “this is a final overrider.”

Example, bad

struct B {
    void f1(int);
    virtual void f2(int) const;
    virtual void f3(int);
    // ...
};

struct D : B {
    void f1(int);        // bad (hope for a warning): D::f1() hides B::f1()
    void f2(int) const;  // bad (but conventional and valid): no explicit override
    void f3(double);     // bad (hope for a warning): D::f3() hides B::f3()
    // ...
};

Example, good

struct Better : B {
    void f1(int) override;        // error (caught): Better::f1() hides B::f1()
    void f2(int) const override;
    void f3(double) override;     // error (caught): Better::f3() hides B::f3()
    // ...
};

Discussion

We want to eliminate two particular classes of errors:

• implicit virtual: the programmer intended the function to be implicitly virtual and it is (but readers of the code can’t tell); or the programmer intended the function to be implicitly virtual but it isn’t (e.g., because of a subtle parameter list mismatch); or the programmer did not intend the function to be virtual but it is (because it happens to have the same signature as a virtual in the base class)
• implicit override: the programmer intended the function to be implicitly an overrider and it is (but readers of the code can’t tell); or the programmer intended the function to be implicitly an overrider but it isn’t (e.g., because of a subtle parameter list mismatch); or the programmer did not intend the function to be an overrider but it is (because it happens to have the same signature as a virtual in the base class – note this problem arises whether or not the function is explicitly declared virtual, because the programmer might have intended to create either a new virtual function or a new non-virtual function)

Note: On a class defined as final, it doesn’t matter whether you put override or final on an individual virtual function.

Note: Use final on functions sparingly. It does not necessarily lead to optimization, and it precludes further overriding.

Enforcement

• Compare virtual function names in base and derived classes and flag uses of the same name that does not override.
• Flag overrides with neither override nor final.
• Flag function declarations that use more than one of virtual, override, and final.

很简单明确，就是explicitly 写清楚virtual, override或者final. 既增加readability又能catch错误.