www.digitalmars.com         C & C++   DMDScript  

D - Suggestions

reply Matthias Becker <Matthias_member pathlink.com> writes:
- 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)
Nov 02 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"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.
Nov 02 2003
next sibling parent reply "Lars Ivar Igesund" <larsivi stud.ntnu.no> writes:
"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
Nov 02 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
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
Nov 02 2003
parent "Philippe Mori" <philippe_mori hotmail.com> writes:
"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
Nov 03 2003
prev sibling parent "Luna Kid" <lunakid neuropolis.org> writes:
"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.
Nov 03 2003
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
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
Nov 03 2003
parent J Anderson <REMOVEanderson badmama.com.au> writes:
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
Nov 03 2003