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






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.


 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


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




be

 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


so

 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