Writing Bug-Free C/D Code

[Chris Nicholson-Sauls]

Derek Parnell wrote:
> 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.
> 

I often take the same approach, and am quite glad that you do so.  Whenever I find 
unexpected sorts of building errors, for example, I revert to using bud_d.exe for 
subsequent builds until I figure out what's going on, just on the off chance Bud's debug 
code might catch something I'm not, or there may be an error in Bud itself -- hasn't 
happened for me yet, but I'm cautious.  :)

-- Chris Nicholson-Sauls