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.
_______________________________________________
dmd-internals mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals
