Re: [boost] Formal Review: Boost Cast Library

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
>>>dynamic_cast<T &>.
>>
>>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?

  -- Jesse