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

 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

 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

 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

 the assert directs one to the file and line number of the assert

 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

 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

 the assert directs one to the file and line number of the assert

 There, one would expect to find a comment there describing the


 Since one would go there anyway to fix the problem, it seems redundant


 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

 and asserts if they are not. If a message could be supplied, the user

 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

 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

 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

 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

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