Writing Bug-Free C/D Code

Derek Parnell derek at nomail.afraid.org
Wed Mar 21 15:51:49 PDT 2007


On Wed, 21 Mar 2007 09:49:20 -0700, Sean Kelly wrote:

> 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.  

Again, please note that the OP was asking about contracts *as implemented
by D*, and that is what I restricted my comments to.

> That input arguments must be within the proper range, etc, 
> is a precondition, and the purpose of the 'in' clause is to check 
> preconditions.  

However, one can compile it out of the code via a -release so I was saying
that one must not rely on such contract code actually executing in a
production release edition of the program. 

Yes, input data, especially stuff that originates from outside of the
application really ought to be validated at some stage, but 'in' blocks are
not the best places if one is using the current implementation of D.

> 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. 


And yet, DigitalMars has decided that 'in' blocks can be optionally
compiled. I agree in principle with the idea that input data ought to be
validated, but I would recommend that one does not use 'in' blocks to do
that important task.

>   Should we just ignore the 'in' clause altogether then?  

No, of course not. But using the current D implementation, one should not
rely on it for production editions of your application. Use it only for
development editions. Then, armed with this implementation of precondition
contracts, one should use them to validate the logic of your algorithms and
not the validity of incoming data.

> Or assert()? 

No, of course not. But as asserts are not guaranteed to execute in
production editions, one should just use them in development editions. Of
course, you are quite at liberty to distribute both a 'debugging' edition
along with the 'lean&mean' production edition of your application. For
example, I do this with Bud.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
22/03/2007 9:40:56 AM



More information about the Digitalmars-d mailing list