Contract Programming

Building contract support into the language makes for:

1. a consistent look and feel for the contracts
2. tool support
3. it's possible the compiler can generate better code using information gathered from the contracts
4. easier management and enforcement of contracts
5. handling of contract inheritance

Contracts in Digital Mars C/C++ introduce the following new keywords:

	    __in
	    __out
	    __body
	    __invariant		(for C++)

Contracts are enabled by throwing the -D compiler switch. If the -D switch is not thrown, the contract code is not generated or executed. Source files with contracts compiled with -D can be freely intermingled with source files with contracts not compiled with -D.

Assert Contract

The most basic contract is the assert. An assert inserts a checkable expression into the code, and that expression must evaluate to true:

	assert(expression);

Pre and Post Contracts

The pre contracts specify the preconditions before a function body is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the function, which are its return value and any side effects. The syntax is:

	function declaration(parameters)
	__in
	{
	    ...contract preconditions...
	}
	__out (result)
	{
	    ...contract postconditions...
	}
	__body
	{
	    ...code...
	}

Either the __in or the __out clause can be omitted. If the out clause is for a function body, the variable result is declared and assigned the return value of the function. For example, let's implement a square root function:

	long square_root(long x)
	    __in
	    {
		assert(x > 0);
	    }
	    __out (result)
	    {
		assert((result * result) == x);
	    }
	    __body
	    {
		return sqrt(x);
	    }

If the function returns a void, there is no result, and so there can be no result declaration in the out clause. In that case, use:

	void func()
	   __out
	   {
		...contracts...
	   }
	   __body
	   {
		...
	   }

Class Invariants (C++ only)

Class invariants are used to specify characteristics of a class that always must be true (except while executing a member function). For example, a class representing a date might have an invariant that the day must be 1..31 and the hour must be 0..23:

	struct Date
	{
	    int day;
	    int hour;

	    __invariant()
	    {
		assert(1 <= day && day <= 31);
		assert(0 <= hour && hour < 24);
	    }
	};

The class invariant is a contract saying that the asserts must hold true. The invariant is checked when a class constructor completes, at the start of the class destructor, before a public member is run, and after a public function finishes. Class invariants are inherited, that is, any class invariant is implicitly anded with the invariants of its base classes. Class invariant functions can be declared virtual, and as a general rule, they should be virtual if and only if the class destructor is virtual.

When compiling for release, the invariant code is not generated, and the compiled program runs at maximum speed.

Future Directions with DBC

If the function is virtual, the __in clause needs to be OR'd with the __in clauses of any functions it overrides in all the base classes. Similarly, the __out clause needs to be AND'd with all the __out clauses.

__in clauses should not be able to modify the function parameters.

When an __out clause references a function parameter, the value should be the same as when the function was called, and not what it is after the function body may have modified it.

Currently, contracts rely on the assert() macro aborting the program with a message. Perhaps this needs to be revisited, and changed to throw an exception instead.

Legacy Compilers

Contract code can be ported to legacy compilers by using #ifdef's:

	void foo()
	#ifdef __DMC__
	    __in
	    {
		...
	    }
	    __body
	#endif
	    {
	    }

References