(ref.doc)The Gnu C++ Library

p 24-27
The Gnu C++ Library
Ahead of its time
by Doug Lea

"Constructive" functions in ADT (e.g. accept two complex numbers and
return a third), versus "mutative" methods, in the OO approach.

It is impossible to declare a constructive version of a method for an
abstract class. (A workaround would be to declare it to return a
pointer or reference. But this interferes with value semantics and
leads to storage management responsibility problems).

Libg++ contains substantially more components like Complex than those
like BankAccount. Many classes maintain "value semantics", in a manner
more similar to classic ADT approaches than to classic OO approaches.

The only general solution (for storage management) is to rely on
automatic storage management (garbage collection).

Value approaches traditionally lie in the world of overloading and
parameterization, while OO approaches obtain generality via
inheritance.

The net result of these considerations is that value-oriented classes
are not readily subclassable in C++. The best two solutions are the
most extreme: Either give up on value semantics (at least for
troublesome operations) or give up on subclassability for classes with
extensive reliance on constructive functions.
Most "lightweight" classes (e.g. strings, multiple precision numbers,
bit sets) take the latter option. In consequence:
- Class interfaces are very extensive. The base classes provide
  functionality that, although rarely needed, is otherwise difficult
  to support without subclassing.
- No operations are virtual, and many are inlinable.

Container classes may be used in different roles:
- collections
- repositories

Most classes themselves include an internal invariant check method
OK().