Design by Contract Programming in C

Design by Contract Programming in C++
The Eiffel programming language introduced "design by contract" to objectoriented programming. The main idea here is to model interfaces between classesas contracts. In this article, we will be applying this powerful technique toC++ programming.
Interfaces as Contracts
In legal terms, a contract is a binding document that describes theresponsibilities and expectations of the parties entering into thecontract.Interfaces between classes can be modeled in the same way. Whenever anobject invokes a method of an other object, this interactionshould be viewed as a contract between the caller and the called method.Thiscontract consists of the following conditions:
Pre-conditions. The caller of the method needs to pass parameters that meet the requirements of the called method. Pre-conditions check if the caller of the method is keeping its side of the contract by passing the right parameters.
Post-conditions. The called method needs to return results that meet the expectations of the caller. Post-conditions check if the called method is keeping its side of the contract, i.e. returning the results required by this interface.
Consistency checks. In addition to the pre-conditions and post-conditions, all the objects involved in the transaction should be left in a consistent state.
Design by Contract Framework
We will consider an example here to see how "design by contract" is implementedin C++. We start by looking at the basic framework for design by contract. Theframework consists of the following macros that are available only in the debugmode. The macros are defined to blank in the release build.
ASSERT: This macro aborts the program if the parameter passed to the macro does not evaluate to true. When this macro is used in the code, the programmer is asserting that the condition specified in the parameter has to be true. If it is not so, further execution of the program cannot proceed.
IS_VALID: This macro is used to check the consistency of an object. The programmer invokes this method before acting on an object pointer. This method invokes the virtual function IsValid to perform the consistency checks associated with the class.
REQUIRE: This macro should be used to check if the pre-conditions for the invoked method have been met. If the caller does not keep its part of the contract, this macro will assert (as it is just another redefinition of ASSERT)
ENSURE: This macro checks if the post conditions have been met. Here the called function checks if it has kept its part of the contract. This macro will assert if there is a contract breach.
IsValid Method: This method is defined in a base class that will act as the parent for all inheriting classes. This method is defined as an abstract function. This forces all programmers to define the function. The code in the inheriting classes should check for consistency of the objects internal state. Also note that this method exists only in the debug build, thus it does not add to code bloat.
Design by Contract Framework
// Object class is the base class for all // objects in the system. All classes inheriting from this class need // to define a method IsValid. This method should perform a // consistency check on the state of the object. Note that // this method needs to be defined only when a debug build is made class Object { public: #ifdef _DEBUG bool IsValid() const = 0; #endif }; #ifdef _DEBUG // The debug mode also defines the following macros. Failure of any of these macros leads to // program termination. The user is notified of the error condition with the right file name // and line number. The actual failing operation is also printed using the stringizing operator # #define ASSERT(bool_expression) if (!(bool_expression)) abort_program(__FILE__, __LINE__, #bool_expression) #define IS_VALID(obj) ASSERT((obj) != NULL && (obj)->IsValid()) #define REQUIRE(bool_expression) ASSERT(bool_expression) #define ENSURE(bool_expression) ASSERT(bool_expression) #else // When built in release mode, the _DEBUG flag would not be defined, thus there will be no overhead // in the final release from these checks. #define ASSERT(ignore) ((void) 0) #define IS_VALID(ignore) ((void) 0) #define REQUIRE(ignore) ((void) 0) #define ENSURE(ignore) ((void) 0) #endif
Debug and Release Builds
The "design by contract" framework can work only if the programmers canintroduce aggressive checks without having to worrying about their performanceimplications. The main idea here is that lab testing of the product should bedone with debug builds (i.e. _DEBUG flag is defined) where all the "design by contract" macros are enabled.These macros will allow you to zero in on the faults very quickly as all breachof contract conditions are being checked. This can dramatically lower thedebugging time in a large project. This means you will have less of thoseunhealthy finger pointing sessions when bugs have to be isolated.
When the product is ready to be shipped, the release build can be made. Thisbuild will disable all the macros used in the "design by contract" framework.Thus you will obtain complete performance. If CPU performance is not a big issue,in the initial deployment you may decide to retain the macros and replace theexit condition in the ASSERT macro with exception throwing. Thus you havecomplete control on the level of debugging you wish to have in the finalproduct.
An important thing to note here is that the "designby contract" framework is not a replacement for defensive programming. You stillwrite defensive code which handles error conditions even in the release build.You can view the contract checking as a diagnostic programming technique thatallows you to be extra suspicious in handling contracts when the implementationof the contract is new and untested. When you get comfortable with the contractimplementation, you turn off the extra suspicious checking.
Another benefit of "design by contract" technique is that it gives you extradiagnostic capability without compromising readability. There is no need to addredundant if statements for diagnostic programming.  In fact, these macroswill actually improve the readability as they clearly state the expectations ofthe caller and the called methods.
An Example of Design by Contract Programming
Here we have taken an example from theSTL Design Patterns articleand added support for the "design by contract" framework. All the additions tothe originalTerminal Manager are shown in bold.
Terminal Manager
#include