Imperfect C++

Breaking Up The Monolith is not a follow-up to my 2004 book Imperfect C++, so my mentioning it here is just gratuitous self-publication.

Nonetheless, there are several parts of Breaking Up The Monolith where familiarity with Imperfect C++ will be helpful.

Extended STL, volume 1

For the record, Breaking Up The Monolith is not a follow-up to my 2007 book Extended STL, volume 1, either. :-].

Nonetheless, several of the issues discussed in depth in Breaking Up The Monolith are raised in Extended STL, volume 1.

Breaking Up The Monolith

Advanced C++ Design without Compromise

Glossary of Terms

Breaking Up The Monolith describes techniques for writing and working with C/C++ libraries effectively, efficiently and with minimal coupling.

This page contains a glossary of terms used within the book:

Abstraction Dissonance
The condition whereby client code is written using units of currency that exist at a higher level of abstraction than those used by the libraries/APIs in terms of which the client code is written.
Contract Enforcement
The act of verifying actual conditions against expected conditions, and reacting if they differ.

Contract enforcements can be undertaken at compile time and at runtime.
Contract Programming
The practice of specifying and, optionally, enforcing contracts within the limitations imposed by a given language, operating environment, and design and development constraints.
Correctness
The consistency of its implementation with its specification.
Defect
An aspect of a software system that may cause the system to depart from its intended behaviour.

A defect is the potential for a fault.

If the defect is downstream from the design phase, then it will represent a design violation, and may be policed using contract programming enforcements.

Enforcement Indivisibility, The (Rule)
Each enforcement should test a single condition of a contract.
Error
A wrong decision made during the development of a software system.
Failure
The condition whereby a software system does not provide the functionality prescribed by its specification

Failures may be caused by failure in design or in coding.
Fault
The event of a software system behaving in conflict with its design.

A fault is the reification of a defect.
Header-Only
A C and/or C++ library all of whose elements are contained in include (header) files, requiring no link-time dependencies.
Irrecoverability (Principle)
The principle of irrecoverability states: It is not possible for a software system to operate in accordance with its design if any component part of that system has violated its design. A system executing in such a state must be stopped immediately.
Non-redundancy (Principle)
The principle of non-redundancy states*: Under no circumstances shall the body of a routine ever test for the routine's precondition.
Removability (Principle)
When applied to contract enforcement, the principle of removability states: A contract enforcement should be removeable from correct software without changing the (well-functioning) behaviour.

When applied to logging, the principle of removability states: It must be possible to disable any log statement within correct software without changing the (well-functioning) behaviour.
Shim (Concept)
An unbounded set of function overloads that generalise between (aspects of) conceptually related but physically unrelated types. A shim is defined by four characteristics: Name, Intent, Category and Ostensible Return Type.
Shim, Characteristic: Category
The intent, behaviour and constraints on the use of a shim. Shim categories can be fundamental (Attribute, Control, Conversion & Logical) or composite (combinations of two or more shim categories).
Shim, Characteristic: Intent
The common purpose of all functions constituting the shim.
Shim, Characteristic: Name
A fully-qualified name, consisting of namespace name + function name, that is shared by all function overloads comprising the shim.
Shim, Characteristic: Ostensible Return Type
The type to which the return type of all overloads of a given shim are implicitly convertible.
Shim, Concept (composite): Access
Shim, Concept (composite): Action
Shim, Concept: Attribute
Shim, Concept: Conversion
Shim, Concept: Control
Shim, Concept: Logical
Shim, Degenerate
The degenerate form of a shim is the overload (or template) whose argument is equivalent to the ostensible return type of the shim; only attribute and access shims have degenerate forms.

In all cases, the degenerate form of a shim function does no allocation or conversion (other than cv-qualifier conversion).
Type Tunnel (Pattern)
A Type Tunnel describes the situation where a group of physically-unrelated types may be tunneled through an extensible adaptation layer and presented in unified form to an underlying layer for manipulation as a whole. It consists of the following:
  1. a generic, extensible interface layer, used in client code, which can interact with heterogeneous types, and
  2. a tunnel mechanism, which translates between the heterogeneous types expressed in the client code into the type understood by
  3. a concrete API layer, which manipulates a single concrete type.

Libraries that employ the Type Tunnel pattern include FastFormat, Pantheios and VOLE. All three use N-ary function templates as the interface layer. The first two use shims as the tunnel mechanism, whereas VOLE uses conversion constructors.
Unit of Currency
The primary physical type with which client code represents a given conceptual type. The primary physical type by which a component or API communicates a given conceptual type to its client code.

References