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

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

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

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

Why don't you do something like this?

> in { version(SlowInvariants) _check_stuff(); }
>
> // ...
>
> version(SlowInvariants) {
>     void _check_stuff() {
>         // ...
>     }
> }

Then, when compiling, stick a -version=SlowInvariants on the command line.  You should be able to set up a release and debug target in bud so you only need to do this once.

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

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@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?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
9/11/2006 2:13:20 PM

Derek Parnell wrote:
> On Thu, 09 Nov 2006 12:06:34 +0900, Bill Baxter wrote:
> 

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

Sounds sweet to me.

Not sure if _Doptimized is really useful though.  But if that makes sense, then probably something should be done for -g too.
And what about -run?  I can see a use for that more readily than I can for -O or -g.

I thought I remembered posting something about a wish for a version to go with unittests and somebody posted some kind of patch right away.  I couldn't find it in the archives though.  Oh yes... it was a bug not a ng post.  That's why I couldn't find it:  here it is:

  http://d.puremagic.com/issues/show_bug.cgi?id=458

--bb

On Thu, 09 Nov 2006 12:52:03 +0900, Bill Baxter wrote:

Ok, a more generic technique might be to have Bud add "version=D_<x>" for each simple compiler switch supplied. Such that if "-run" was supplied Bud would add "version=D_run", etc...

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
9/11/2006 2:59:03 PM

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@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?

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


You must have skipped that part of the discussion.
Because I've got some code that I want to share between different contracts, but it should't be compiled in when contracts aren't being used.

--bb

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@billbaxter.com)'s article
>>> Is there a version statement that corresponds to whether or not
>>> contracts are enabled or not?
<snip>
> 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 _check_data_structure_integrity is compiled only if DBC is enabled? That's really a matter of compiler/linker optimisation.  A design principle of D is that language features to compensate for compiler naivety are, in general, omitted.

> So I think something more fine grained than class invariants is needed.  Something like version(_DContracts) would do it.

Why the name _DContracts?


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.