version(CONTRACTS) for contracts?

Hasan Aljudy hasan.aljudy at gmail.com
Wed Nov 8 20:12:24 PST 2006



Derek Parnell wrote:
> On Thu, 09 Nov 2006 12:06:34 +0900, Bill Baxter wrote:
> 
>> BCS wrote:
>>> I think what you are trying for is what class invariants do.
>>>
>>> http://www.digitalmars.com/d/class.html#invariants
>>>
>>> == Quote from Bill Baxter (dnewsgroup at billbaxter.com)'s article
>>>> Is there a version statement that corresponds to whether or not
>>>> contracts are enabled or not?
>>>> I'd like to do something like
>>>>    in { _check_data_structure_integrity() }
>>>> for a bunch of my methods in my class, then something like
>>>>     version(Contracts) {
>>>>        _check_data_structure_integrity() {
>>>>           // do a bunch of complicated stuff here
>>>>           // and assert if anything's messed up.
>>>>        }
>>>>     }
>>>> --bb
>> Class invariants. Indeed so!
>>
>> Still I don't think that covers all use cases.  If my invariant is very 
>> slow to compute and I have some methods that are very frequently called, 
>> then I'm not going to want to check it for every single method call.  It 
>> could make debugging way too slow.  Plus, if I know these three methods 
>> are the only three that affect this invariant then only those three 
>> methods should trigger an invariant check.
>>
>> So I think something more fine grained than class invariants is needed. 
>>   Something like version(_DContracts) would do it.
>>
>> --bb
> 
> I can do this with the next Bud. 
> 
> If "-release" is used, I can add "version=_Drelease" to the command line.
> If "-release" is *not* used, I can add "version=_Dcontracts" to the command
> line.
> If "-unittest" is used, I can add "version=_Dunittest" to the command line.
> If "-O" is used, I can add "version=_Doptimized" to the command line.
> 
> Is anyone interested in this idea? Does it need tweaking? 
> 

But why? I don't get it.
If -release is passed, then contracts won't run anyway, so who needs a 
version identifier for it?



More information about the Digitalmars-d mailing list