- Assert Expressions
It might be helpfull, if you could optionaly pass a string literal to assert. So
you could give informations on why and where the assertion failed.

assert (condition, "Balblabla");



(quote from D's documentation)
Insertion of array bounds checking code at runtime should be turned on and off
with a compile time switch.
(/quote)

It might be interesting to do this with a keyword:

(pseudocode)
checked {
my_array[index] = value;
// checked even if the compiletime switch is turned off
}
(/pseudocode)

"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:bo360b$gpo$1@digitaldaemon.com...

Your other post has a lot of good ideas in it. Thanks.

> - Assert Expressions
> It might be helpfull, if you could optionaly pass a string literal to
assert. So
> you could give informations on why and where the assertion failed.
>
> assert (condition, "Balblabla");

This has been asked for several times. The reason it isn't there is because the assert directs one to the file and line number of the assert statement. There, one would expect to find a comment there describing the situation. Since one would go there anyway to fix the problem, it seems redundant to print another message to the screen.

> (quote from D's documentation)
> Insertion of array bounds checking code at runtime should be turned on and
off
> with a compile time switch.
> (/quote)
>
> It might be interesting to do this with a keyword:
>
> (pseudocode)
> checked {
> my_array[index] = value;
> // checked even if the compiletime switch is turned off
> }
> (/pseudocode)

I've been thinking of an implementation defined attribute where D compiler implementors could add all kinds of instructions to the compiler in a defined, portable way.

"Walter" <walter@digitalmars.com> wrote in message news:bo3jjv$152h$1@digitaldaemon.com...

> > - Assert Expressions
> > It might be helpfull, if you could optionaly pass a string literal to
> assert. So
> > you could give informations on why and where the assertion failed.
> >
> > assert (condition, "Balblabla");
>
> This has been asked for several times. The reason it isn't there is
because
> the assert directs one to the file and line number of the assert
statement.
> There, one would expect to find a comment there describing the situation. Since one would go there anyway to fix the problem, it seems redundant to print another message to the screen.

In the "asserts for developers" case yes. In the "asserts for users" case
no.
Think of a library, possibly closed source, where a certain function takes
floats as input arguments. The function needs these floats to be above zero
and asserts if they are not. If a message could be supplied, the user could
be alerted that he use the function in question wrong (function name and
parameters.) Very handy. I've seen it myself.

Lars Ivar Igesund

In principal, assertions should only be for debug mode and developer's eyes.

In practise, however - embedded systems, alpha releases, lazy programmers, too-simple-to-fuss utilities - they are often not. I agree we should have nicer assert support.



"Lars Ivar Igesund" <larsivi@stud.ntnu.no> wrote in message news:bo41ij$1oil$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:bo3jjv$152h$1@digitaldaemon.com...
>
> > > - Assert Expressions
> > > It might be helpfull, if you could optionaly pass a string literal to
> > assert. So
> > > you could give informations on why and where the assertion failed.
> > >
> > > assert (condition, "Balblabla");
> >
> > This has been asked for several times. The reason it isn't there is
> because
> > the assert directs one to the file and line number of the assert
> statement.
> > There, one would expect to find a comment there describing the
situation.
> > Since one would go there anyway to fix the problem, it seems redundant
to
> > print another message to the screen.
>
> In the "asserts for developers" case yes. In the "asserts for users" case
> no.
> Think of a library, possibly closed source, where a certain function takes
> floats as input arguments. The function needs these floats to be above
zero
> and asserts if they are not. If a message could be supplied, the user
could
> be alerted that he use the function in question wrong (function name and parameters.) Very handy. I've seen it myself.
>
> Lars Ivar Igesund
>
>

"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> a écrit dans le message de news:bo45b2$1u0i$1@digitaldaemon.com...
> In principal, assertions should only be for debug mode and developer's
eyes.
>
> In practise, however - embedded systems, alpha releases, lazy programmers, too-simple-to-fuss utilities - they are often not. I agree we should have nicer assert support.
>
>
>

And even for programmer, if it is possible to write customized message
(that is a formatted message that will show some values), the programmer
might have have a better idea of the problem (unintialized value, off by
one,
very near the limit (for flotting points) or rounding errors...).

    double d = something();
    ASSERT(d >= 0.0, d);

If the programmer see -0.00001 as the value, he will deduce a rouding error,
if he see 1.34e301, he will deduce unintialized variable, if he see NAN
he will knows that some mathematical errors have occured...

Essentially, this is like a TRACE controled by an ASSERTION...

Philippe

"Walter" <walter@digitalmars.com> wrote in message news:bo3jjv$152h$1@digitaldaemon.com...
>
> "Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:bo360b$gpo$1@digitaldaemon.com...

> > - Assert Expressions
> > It might be helpfull, if you could optionaly pass a string literal to
> assert. So
> > you could give informations on why and where the assertion failed.
> >
> > assert (condition, "Balblabla");
>
> This has been asked for several times. The reason it isn't there is because the assert directs one to the file and line number of the assert statement. There, one would expect to find a comment there describing the situation. Since one would go there anyway to fix the problem, it seems redundant to print another message to the screen.

At first I completely agreed Walter's argument.

Then I thought I rarely comment asserts, because usually the assert *itself* is the comment to me.

And then I also thought that, hey, one doesn't want to
go and fix the *assert*, but one wants to go and fix the
*bug* that triggered the assert. So, one only goes and visit
the assert at the indicated place only to see what the exact
condition that failed, actually was. Then immediately I go
away from there and go search for the bug. (So I very much
consider an uncomprehensible crime that the C/C++ std lib
authors do not at least print the darned expression itself
that failed -- a thing almost every single 3rd party lib
vendor's own assert macro does...)

The point, if I could write something like

    assert(expr, "some note to myself");

instead of

    assert(expr); // some note to myself

Then I would lose nothing, I'd introduce no added redundancy,
but I'd get significant extra help for free, possibly to
the extent that I'd never again need to visit the assert
first, but could immediately go to where I guess the problem
really is.

So, now I also started liking Matthias's idea, and I think I go and add this support to my DBG.H... (The only thing is there is no default macro argument in C++ :-/ )

Cheers,
Sz.

Matthias Becker wrote:
> - Assert Expressions
> It might be helpfull, if you could optionaly pass a string literal to assert. So
> you could give informations on why and where the assertion failed.
> 
> assert (condition, "Balblabla");

D's current Assert only prints file and line - which definately makes sense in release builds, which might have asserts enabled. It is quite another matter of views and of taste, whether releases should at all contain asserts, but if they do they should not contain any code as text or even comments.

However, when debugging it might be neat if the assert could print its expression. Thus the old C trick could be reused:

assert (condition && "Blablabla");

It does trigger the assertion correctly in D.

-eye

Ilya Minkov wrote:

> Matthias Becker wrote:
>
>> - Assert Expressions
>> It might be helpfull, if you could optionaly pass a string literal to assert. So
>> you could give informations on why and where the assertion failed.
>>
>> assert (condition, "Balblabla");
>
>
> D's current Assert only prints file and line - which definately makes sense in release builds, which might have asserts enabled. It is quite another matter of views and of taste, whether releases should at all contain asserts, but if they do they should not contain any code as text or even comments.
>
> However, when debugging it might be neat if the assert could print its expression. Thus the old C trick could be reused:
>
> assert (condition && "Blablabla");
>
> It does trigger the assertion correctly in D.
>
> -eye
>
>
Ilya Minkov wrote:

> Matthias Becker wrote:
>
>> - Assert Expressions
>> It might be helpfull, if you could optionaly pass a string literal to assert. So
>> you could give informations on why and where the assertion failed.
>>
>> assert (condition, "Balblabla");
>
>
>
>
> D's current Assert only prints file and line - which definately makes sense in release builds, which might have asserts enabled. It is quite another matter of views and of taste, whether releases should at all contain asserts, but if they do they should not contain any code as text or even comments.
>
> However, when debugging it might be neat if the assert could print its expression. Thus the old C trick could be reused:
>
> assert (condition && "Blablabla");
>
> It does trigger the assertion correctly in D.
>
> -eye
>
>
Of course then you don't get value outputs (other then strings) with that.

You could write your own function to do it (pseudo)...

bit test(bit cond, ...)
{
if (!cond)
 printf(...); //Line is not correct, but would be nice syntax sugar for variable arguments

return cond;
}

Then you could write (example):

assert(test(A[n] < B[n], "A[1] = %f, n = %d, m = %d", A[1], n, m));

Parhaps it should be part of the std?

It wouldn't work for static asserts for course, but then I can't see a need for this kinda output for static asserts.

IMHO: I think that assert output can be useful. If your just going to go to the line in a file, you can't see all the relevant numbers that caused it to crash and tracing seems a bit heavy duty (in many cases). Moreover, some errors are hard to repeat and you only have one chance to get the numbers. Particularly if your a product tester (software or human), testing a debug build, and need to send the error back to the programmers, who will most likely try to repeat the error.

-Anderson