www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Design by contract on/off

reply Victor Nakoryakov <nail-mail mail.ru> writes:
Hello all.

Maybe I'm not understand design by contract ideology completly, but I'd 
like to be able to compile module ignoring all "assert", "invariant" and 
"out" statements and leaving "in" and "unittest"s. For stable modules 
such compiler flag can speed up module routines by ignoring 
performance-expensive conditions in above statements but in the same 
time guarantee work correctness by controling input arguments in "in" 
statements.

In another words when your module works as expected the only thing that 
can corrupt its stable work is unexpected input arguments from another 
modules that use it. So it would be nice if I can control external 
effect and ignore internal bug traps.

-- 
Victor (aka nail) Nakoryakov
nail-mail<at>mail<dot>ru

Krasnoznamensk, Moscow, Russia
Jun 26 2005
next sibling parent reply Nick <Nick_member pathlink.com> writes:
Victor Nakoryakov says...
Hello all.

Maybe I'm not understand design by contract ideology completly, but I'd 
like to be able to compile module ignoring all "assert", "invariant" and 
"out" statements and leaving "in" and "unittest"s. For stable modules 
such compiler flag can speed up module routines by ignoring 
performance-expensive conditions in above statements but in the same 
time guarantee work correctness by controling input arguments in "in" 
statements.

In another words when your module works as expected the only thing that 
can corrupt its stable work is unexpected input arguments from another 
modules that use it. So it would be nice if I can control external 
effect and ignore internal bug traps.

You remove all these tests (except the unittests) with the -release flag. You're not supposed, according to the contract ideology, to put checks for runtime conditions in the contracts, only the "internal bug traps". In other words, you will have to put the controls for external effects in the function's body. Nick
Jun 26 2005
parent reply Victor Nakoryakov <nail-mail mail.ru> writes:
Nick wrote:

 You remove all these tests (except the unittests) with the -release flag.
You're
 not supposed, according to the contract ideology, to put checks for runtime
 conditions in the contracts, only the "internal bug traps". In other words, you
 will have to put the controls for external effects in the function's body.
 
 Nick

Oh, I'm totally forgot that unittests are enabled/disabled with separate compiler flag, sorry. I think you didn't understand me completely. Maybe it would be better if I explain my idea on example. Consider module module matrix; ... void polarDecomposition(in Matrix44 M, out Matrix44 Q, out Matrix44 S) in { assert(M.isAffine); } out { assert(Q.isRotation); assert(S.isDiagonal); } body { ... ... assert(someInternalVal < 10); assert(someInternalMat.inverse.transposed == someInternalMat); ... ... } ... Well if I'm sure that the algorithm is correct I need not to check that the result is unexpected and I can skip expensive internal asserts that performs matrix inversion on each of N iterations. But I'd like to preserve input argument checking, because if it would not satisfy algorithm requirements the results will be unpredictable. And then when I will release final version of my product I would want to totally disable all contract checking. -- Victor (aka nail) Nakoryakov nail-mail<at>mail<dot>ru Krasnoznamensk, Moscow, Russia
Jun 26 2005
parent reply Nick <Nick_member pathlink.com> writes:
I think you didn't understand me completely. Maybe it would be better if 
I explain my idea on example. Consider module

body
{
	...
	...
	assert(someInternalVal < 10);
	assert(someInternalMat.inverse.transposed == someInternalMat);
	...
	...
}
...

Well if I'm sure that the algorithm is correct I need not to check that 
the result is unexpected and I can skip expensive internal asserts that 
performs matrix inversion on each of N iterations. But I'd like to 
preserve input argument checking, because if it would not satisfy 
algorithm requirements the results will be unpredictable. And then when 
I will release final version of my product I would want to totally 
disable all contract checking.

Ok, I think I understand. What you are saying is that you would like to remove some asserts, and keep others, right? Is it possible to solve this by using version or debug statements? What I would do (and have done) in this situation is
 debug(expensiveChecks)
 {
   assert(someInternalVal < 10);
   assert(someInternalMat.inverse.transposed == someInternalMat);
 }

and remove the appropriate -debug switch when it's no longer need. Or in some cases just use good all fasioned /*comments*/ :) Nick
Jun 27 2005
parent Victor Nakoryakov <nail-mail mail.ru> writes:
Nick wrote:
 
 Ok, I think I understand. What you are saying is that you would like to remove
 some asserts, and keep others, right?

I would like to remove all asserts that are not in in { ... } scope.
 Is it possible to solve this by using
 version or debug statements? What I would do (and have done) in this situation
 is

Possible, of course. But separate solution is more elegant. -- Victor (aka nail) Nakoryakov nail-mail<at>mail<dot>ru Krasnoznamensk, Moscow, Russia
Jun 28 2005
prev sibling next sibling parent Stefan Zobel <Stefan_member pathlink.com> writes:
In article <d9m5t2$2ln5$2 digitaldaemon.com>, Victor Nakoryakov says...
Hello all.

Maybe I'm not understand design by contract ideology completly, but I'd 
like to be able to compile module ignoring all "assert", "invariant" and 
"out" statements and leaving "in" and "unittest"s. For stable modules 
such compiler flag can speed up module routines by ignoring 
performance-expensive conditions in above statements but in the same 
time guarantee work correctness by controling input arguments in "in" 
statements.

In another words when your module works as expected the only thing that 
can corrupt its stable work is unexpected input arguments from another 
modules that use it. So it would be nice if I can control external 
effect and ignore internal bug traps.

-- 
Victor (aka nail) Nakoryakov
nail-mail<at>mail<dot>ru

Krasnoznamensk, Moscow, Russia

+1 I'm also missing that (think about the viewpoint of someone who's writing a library, for example). BTW, I don't think D's distinction between release and debug builds in this respect has anything to do with the DBC idea in general (as I understand it). Just my 2 c, Stefan
Jun 26 2005
prev sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Victor Nakoryakov" <nail-mail mail.ru> wrote in message 
news:d9m5t2$2ln5$2 digitaldaemon.com...
 Hello all.

 Maybe I'm not understand design by contract ideology completly, but I'd 
 like to be able to compile module ignoring all "assert", "invariant" and 
 "out" statements and leaving "in" and "unittest"s. For stable modules such 
 compiler flag can speed up module routines by ignoring 
 performance-expensive conditions in above statements but in the same time 
 guarantee work correctness by controling input arguments in "in" 
 statements.

 In another words when your module works as expected the only thing that 
 can corrupt its stable work is unexpected input arguments from another 
 modules that use it. So it would be nice if I can control external effect 
 and ignore internal bug traps.

 -- 
 Victor (aka nail) Nakoryakov
 nail-mail<at>mail<dot>ru

 Krasnoznamensk, Moscow, Russia

agreed (though possibly not necessarily about the unittest being included with in contracts). Currently 'in' contracts shouldn't be used for input validation for any routine destined for a library (IMHO). In particular several bugs in std.stream would have been caught ages ago if the 'in' contracts had been enforced in the shipping build. When I moved the 'in' contracts contents to the body people found their code stopped working.
Jun 29 2005