C++ Strategies and Tactics

Reading notes, by Marc

Unfortunately slightly obsolete: covers the USL components, and displays a dated, overly conservative, use of C++, supporting data abstraction more than object orientation.
Otherwise, clear and convincing, especially when consistently attempting in various ways to specify semantics.

p 93 4.4 Protected inheritance

I have never used protected inheritance, and I have never heard of it being used in a real project.

[...] if you can use composition, you should: the use of obscure corners of the language (like protected inheritance) makes programs harder to understand.

p 94 4.5 Conformance to base class abstractions

The member function in the derived class should conform to the abstract model of the base class.

p 99 4.6 Pure virtual functions

A destructor should never be pure.

p 108
[The relationship between types and declared things in C++, expressed through Venn diagrams]

p 134-135 6.3.1 Abstract base classes
[operator<< is defined along with the abstract class, using the virtual output member]

An abstract class can provide some functionality.

p 146 7.2 Some template details
[Obsolete: it is possible now to make class templates your friends, although not with the syntax prospected here]

p 171-172 8.3.2 Automatic resize
[Good analysis of a bug bound to an attempt to resize a block automatically]

p 191 Chapter 9, Reusability [A reference on reuse]

p 213-214 9.2.4 The Linton convention

Functions should not store pointers to reference arguments in any location that will persist after the function returns. Functions that need to do this should use pointer arguments instead.

p 223 9.5.1 Placement syntax and operator delete

[...] there is no way to pass arguments to operator delete.

p 240

inline void*
Thing::operator new(size_t bytes) {
    assert(bytes == sizeof(Thing));
    return pool.alloc();
}