[dmd-internals] changeset 455

[Walter Bright]

Steve Schveighoffer wrote:
>
> But I meant that when unittests were disabled, the assert handler linked would be the faster variety, and when unittests were enabled, the assert handler would be the comprehensive unittesty variety.  The object files would be identical, it's just what assert function do you link with.  I don't know if it's possible, which is why I asked.
>
> If that's not possible, we still have another option.
>
> An assert translates roughly to this:
>
> if(!condition) {throwAnError();}
>
> We all agree that when throwAnError is called, performance is out the window (nobody but the runtime should be catching asserts, and we should expect the program to exit soon after since it's in an invalid state).  Why can't the check for whether we're in unittest mode be inside that function/block as Andrei pointed out?  My larger point is simply that we should not consider performance problems to be important during unit testing, asserts can be slow, because unittests do not need to be as fast as possible.
>
>   

What I meant was that the compiler takes advantage of knowledge that 
assert() failures do not return to generate better code for the 
non-asserting case. I agree that the performance of the asserting case 
is not relevant.