Writing Bug-Free C/D Code

[Sean Kelly]

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

Okay, this is a valid point.  I just happen to disagree with it :-)  I 
feel that this is what 'in' contracts are for, and if the user doesn't 
want that security then it's their prerogative to turn it off.

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

Or assert, I suppose, since it is disabled too.  This leaves D in the 
same situation as C/C++, and I refuse to do this simply because the user 
has the option to disable it.

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

But this suggests that I should either do parameter checking both in the 
'in' clause and in the function body using separate implementations 
(since assert is not an option).  This complicates maintenance, hurts 
readability, and reduces the overall utility of the contract programming 
features IMO.

>> 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'd like to do this with Tango, but it is not an option for the simple 
install (ie. where the full runtime is bundled in phobos.lib), since 
that lib is implicitly linked.  By the way, can someone tell me what is 
included when both -debug and -release are set?


Sean