🚀 go-pugleaf

In article <jzuqcm@bmtech.demon.co.uk>, Scott Wheeler <scottw@bmtech.demon.co.uk> writes:
>
>Perhaps a concrete programming example would help. I assume you know 
>C:, so let's consider the standard library functions that take a string 
>argument. For most, e.g. sscanf(), it is necessary to provide a pointer 
>to character that is not null, i.e. this is implicitly part of the 
>contract. For a few, e.g. strtok(), a null pointer is acceptable. This 
>is documented in the library description, but the system will not help 
>you to check that your code fulfills this part of the contract. If 
>Meyer were to have written the C libraries (under extreme duress!), you 
>would probably find that he would put an assert() macro at the start of 
>sscanf's definition to check that you did in fact provide a valid 
>pointer. Eiffel adds a few bells and whistles to this, like the ability 
>to switch the checking on and off easily and check with different 
>levels of enforcement. Equally important, the "short" view of a class 
>in the environment, which roughly corresponds to a C header for a 
>class, shows the arguments and the contract for functions.

I basically agree with you but IMHO, the most important "bells and whistles"
to the Design by Contract idea in Eiffel is that assertions are inherited
by subclasses. That way you can constrain the implementor of an abstract
(i.e. deferred, pure virtual) method to meet the requirements specified in its contract.

This is where I find the assert.h package too much limited in C and C++.
If someone has an idea on how to emulate this mechanism in C++, I'm a taker.

-------
Jean-Marc Jezequel               Tel : +33 99847192         
IRISA/CNRS                       Fax : +33 99847171         
Campus de Beaulieu               e-mail : jezequel@irisa.fr 
F-35042 RENNES (FRANCE)          http://www.irisa.fr