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

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

"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

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

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

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

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.

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

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