From: Jesse Jones (jesjones_at_[hidden])
Date: 2000-12-08 22:02:49
>>There's lot of code that really can't be unit tested very effectively.
>>For example, 3/4 of my numeric casts are probably in my low level Mac GUI
>>code where I have to convert ints to shorts. It's hard to unit test a
>>window or a checkbox...
>In which case, it seems quite clear that what you need here is a
>runtime-checked conversion not a debug statement. If you cannot
>adequately path test the code, then assume the worst. numeric_cast in
>its current form is the correct tool for the job, from the sounds of it.
I didn't say that it can't be tested. I said that it can't be easily unit
tested. If I'm doing a cast that should *never* fail then I don't want to
throw. All that will do is bloat my exe with extra entries in the
exception tables and screw over the optimizer.
>>>And finally, there is the point that, as a checked cast, numeric_cast is
>>>consistent with the existing language. The example it follows closest is
>>Hmm, I believe you're right. You leave me no alternative but to fall back
>>on C++'s famed obsession with performance. :-) So, I guess my question
>>is, just how badly will an inline function that throws screw up a
>>compiler's code gen?
>If you are doing GUI work I suspect that this would be one of those
>'optimisations' that amounts to a drop in the ocean :->
That's true here but I also sometimes use checked casts to convert from
signed ints to unsigned ints when using STL. I'm sure that at least some
of these are more sensitive to performance. On compilers with
zero-overhead exceptions there's another sort of overhead introduced by
throw statements: each throw will add one(?) entry into the compiler's
exception tables. These tables are not small (eg I just checked one of
my apps built with CW 6 and 200K out of a 1.6M exe are exception tables).
Now these overheads aren't huge, but why should I pay *any* penalty for a
failure that should only happen via a programmer error?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk