Writing Bug-Free C/D Code
Sean Kelly
sean at f4.ca
Wed Mar 21 09:49:20 PDT 2007
Derek Parnell wrote:
> On Wed, 21 Mar 2007 00:35:46 -0800, David B. Held wrote:
>
>> Derek Parnell wrote:
>>> [...]
>>> The trouble is that D's typedef does not allow you to extend the semantics
>>> of the base type, but that's what structs and classes are for, no?
>>>
>>> The Euphoria language has a slightly different type construction mechanism
>>> which has its good side and bad side, but maybe something like it could be
>>> used to extend D's typedef mechanism.
>>> [...]
>> My understanding is that Contracts in D allow you to implement Ada-like
>> SubRanges. This is actually one of the things I really liked about the
>> DbC support. Is that not the case?
>
> Contracts are optional. That is, if something is compiled with the -release
> switch, then contract code is not inserted into the executable. You cannot,
> and must not, rely on contract code for 'production' editions of software.
> It is only meant to be used during the development phases of an
> application, thus you should not use contracts to try and detect invalid
> input data for a function. Contract code should be used to detect logic
> errors and not data errors.
I disagree. That input arguments must be within the proper range, etc,
is a precondition, and the purpose of the 'in' clause is to check
preconditions. My interpretation of your statement is that data
checking is so important that it may not happen as a part of normal
precondition checking. The thing is, *all* preconditions are important.
Should we just ignore the 'in' clause altogether then? Or assert()?
In my opinion, if the user disables contract checking then he is
explicitly stating that he isn't interested in that level of security.
My only regret is that the current crop of D compilers don't offer any
means of linking a separate library for 'debug' and 'release' builds (a
bad choice of words for the associated effects).
Sean
More information about the Digitalmars-d
mailing list