checkedint call removal

Wyatt via Digitalmars-d digitalmars-d at puremagic.com
Wed Jul 30 11:18:22 PDT 2014


On Wednesday, 30 July 2014 at 14:46:20 UTC, Daniel Murphy wrote:
> "Wyatt"  wrote in message 
> news:wpyvrdoofziktwqkzqbf at forum.dlang.org...
>
>> I think the point here is that usually, when the optimiser 
>> changes the semantics of valid code, it's considered a bug in 
>> the optimiser.
>
> s/usually/always/
>
> The thing is, code containing an assertion that is not always 
> true is not valid code.

Seeing this response, my Ordinary Programmer Brain says, "Well 
yeah, of course it's not valid once you remove the assertion; 
you've fundamentally changed the meaning of the whole thing!  If 
it were fine to remove the assertion, I wouldn't have used it in 
the first place."

Something (possibly the thing where "For fastest executables, 
compile with the -O -release -inline -boundscheck=off" is 
standard advice to anyone asking about performance) tells me this 
point needs to be made MUCH more clear wherever possible or the 
ghost of Scott Meyers will haunt us all.  But that it's even a 
problem tells me we're facing a pattern of human error.  Is there 
no good way to eliminate it?

It seems pretty clear that there's a class of runtime check that 
is for debugging only that can be eliminated because you believe 
the code will never be used for evil; and there's a class of 
check where, no matter what, if some condition isn't met the 
application should immediately halt and catch fire lest it do 
something horrible.  Additionally raised in this thread is a 
class of expression that's only evaluated at compile time for the 
sake of making optimisations where you're saying "It's all right, 
I made sure this is good, go to town".

The distinction between the former two things in D apparently 
comes down to whether you put your assert() as its own expression 
or as the ThenStatement of an IfStatement, while the latter has 
been conflated into the first.  That there's prior art regarding 
the terminology and semantics only confuses the issue further.  
Incidentally, this conversation actually forced me to look into 
the semantics of assert() in C and C++, and it turns out it's 
moderately muddy, but it seems they're only eliminated if you 
#define NDEBUG?

-Wyatt


More information about the Digitalmars-d mailing list