www.digitalmars.com         C & C++   DMDScript  

D - Contracts Idea

reply "j anderson" <anderson badmama.com.au.REMOVE> writes:
Hello there,

I think I'd be nice if you could attach an optional comment that'd be
printed at when a contract fails.

assert(expression, "comment");

Although that's not nearly detailed enough, because often variable names are
useful. Perhaps a printf like assert like:

assert(expression, ...);

I'd also be nice to attach delegates to the assert that would be run when it
crashes, and returns some string message.

I guess this is just sugar as it could be done with exception handling.

Anderson
Aug 28 2003
next sibling parent reply Ilya Minkov <midiclub 8ung.at> writes:
j anderson wrote:
 I think I'd be nice if you could attach an optional comment that'd be
 printed at when a contract fails.
 
 assert(expression, "comment");

In raw C you would write: assert (p == NULL && "Description which explains what's wrong"); which does the trick. :))))) -eye
Aug 28 2003
parent reply "j anderson" <anderson badmama.com.au.REMOVE> writes:
"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:bil1er$105a$1 digitaldaemon.com...
 j anderson wrote:
 I think I'd be nice if you could attach an optional comment that'd be
 printed at when a contract fails.

 assert(expression, "comment");

In raw C you would write: assert (p == NULL && "Description which explains what's wrong"); which does the trick. :))))) -eye

Thanks (that was quick), I guess you could go, assert (p == NULL && "for the file " && filename); Anderson
Aug 28 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
j anderson wrote:
 Thanks (that was quick),
 
 I guess you could go,
 assert (p == NULL && "for the file " && filename);

This hack relies on everything being non-null for contract to succeed. And all you get is the exact argument of assert being spit out - no kind of expansion is done. Sorry, this doesn't even work in D, which simply gives you the line where the problem happened. So for now, you can simply add a comment, and keep asserts simple. You are actually right, it does make sense to output some values on assertion. But this is also what a debugger is meant for - since * it can intercept exception throws, which assertions are; * allows you to explore current state of variables; * may display and log incoming debugging messages. BTW, Watcom tools must have a debugger. Is it compatible to the debug information format of digitalmars? -eye
Aug 28 2003
parent reply "j anderson" <anderson badmama.com.au.REMOVE> writes:
"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:bil5ve$177m$3 digitaldaemon.com...
 j anderson wrote:
 Thanks (that was quick),

 I guess you could go,
 assert (p == NULL && "for the file " && filename);

This hack relies on everything being non-null for contract to succeed. And all you get is the exact argument of assert being spit out - no kind of expansion is done. Sorry, this doesn't even work in D, which simply gives you the line where the problem happened. So for now, you can simply add a comment, and keep asserts simple. You are actually right, it does make sense to output some values on assertion. But this is also what a debugger is meant for - since * it can intercept exception throws, which assertions are; * allows you to explore current state of variables; * may display and log incoming debugging messages. -eye

The problem with debuggers, is that you have to search for the values you want to view, and sometimes your using someone elses lib, so you don't know what to look for. If you could assert values, that are most likly the indirect cause, then it would be faster to determine (although 90% of the time, the errors arn't where you expect them). If you could run some sort of delgate function, it may be able to run futher checks on the code variables to come to some better conclusion, and also format the data nicely. The delgate function would probably be passed an instance of the class that it's in and return a string message.
Aug 28 2003
parent "j anderson" <anderson badmama.com.au.REMOVE> writes:
"j anderson" <anderson badmama.com.au.REMOVE> wrote in message
news:bil8iu$1c01$1 digitaldaemon.com...
 "j anderson" <anderson badmama.com.au.REMOVE> wrote in message
 news:bil88u$1be0$1 digitaldaemon.com...
 "Ilya Minkov" <midiclub 8ung.at> wrote in message
 news:bil5ve$177m$3 digitaldaemon.com...
 j anderson wrote:
 Thanks (that was quick),

 I guess you could go,
 assert (p == NULL && "for the file " && filename);

This hack relies on everything being non-null for contract to succeed. And all you get is the exact argument of assert being spit out - no



 of expansion is done.

 Sorry, this doesn't even work in D, which simply gives you the line
 where the problem happened. So for now, you can simply add a comment,
 and keep asserts simple.

 You are actually right, it does make sense to output some values on
 assertion. But this is also what a debugger is meant for - since
   * it can intercept exception throws, which assertions are;
   * allows you to explore current state of variables;
   * may display and log incoming debugging messages.

 -eye

The problem with debuggers, is that you have to search for the values


 want to view, and sometimes your using someone elses lib, so you don't

 what to look for.  If you could assert values, that are most likly the
 indirect cause, then it would be faster to determine (although 90% of


 time, the errors arn't where you expect them).

 If you could run some sort of delgate function, it may be able to run

 checks on the code variables to come to some better conclusion, and also
 format the data nicely.  The delgate function would probably be passed


 instance of the class that it's in and return a string message.

instance = reference. PS - Sorry for the double post

I must be tired, class = object.

Aug 28 2003
prev sibling parent reply John Boucher <John_member pathlink.com> writes:
In article <bil0tc$v8v$1 digitaldaemon.com>, j anderson says...
Hello there,

I think I'd be nice if you could attach an optional comment that'd be
printed at when a contract fails.

assert(expression, "comment");

Although that's not nearly detailed enough, because often variable names are
useful. Perhaps a printf like assert like:

assert(expression, ...);

I'd also be nice to attach delegates to the assert that would be run when it
crashes, and returns some string message.

I guess this is just sugar as it could be done with exception handling.

Anderson

I say that assert() should not be built into the language, there should be a standard version in a standard module, but the programer should be able to write his own if he wants.
Aug 29 2003
parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 I say that assert() should not be built into the language, there should be

to write his own if he wants. But if so, the compiler should consider assert a special function anyway so that: - the compiler can fully optimize it away. - the compiler can issues an error if at compile-time, it is known that the assertion either never or always fail. - there should be a way to obtain context info (file, line, function name, revision number, last modification date, last compilation date, the expression text, and maybe values used in the expression...). In fact, such information (maybe not all) should be available to any function that want it. We should also have compile-time assertion (for when the check can be done at compile time)... If a check can always be done at compile-time, the compiler can issue an error if we uses run-time assertion. We might add a third category where both cases would be allowed: assert - standard assertion (compile and/or run-time check automatically) rtassert - always run-time check (an error if verifiable at compile-time) ctassert - always compile-time (an error if not verifiable at compile-time) For each kind of assertion, we need to be able to provide a user message that ideally could be formatted to include any context information that the programmer wants to output and is available...
Aug 29 2003
parent "j anderson" <anderson badmama.com.au.REMOVE> writes:
"Philippe Mori" <philippe_mori hotmail.com> wrote in message
news:bioj90$9s8$1 digitaldaemon.com...
 I say that assert() should not be built into the language, there should


 a standard version in a standard module, but the programer should be able
 to write his own if he wants.

 But if so, the compiler should consider assert a special function anyway

 that:

 - the compiler can fully optimize it away.

Parhaps the compiler should be able to optimise any code that is not used with hardware or system memory. ... void assertUserDefined(bool exp) { if (ASSERTING) //A constant, would be rejected on optimisation with ASSERTING = false { if (!exp) throw(new assertException(prog.line_number, ect...)); } } ... for (int n=0; n<size; n++) assertUserDefined(n<size); If the user changed a variable to system memory or called a function that accessed hardware (time, video ect...), then the whole thing would be back-tracked to work out what bits affect what bits. I guess that'd be to hard to do fully, otherwise most language compiliers would do it.
Aug 29 2003