Re: [boost] Formal Review: Boost Cast Library

From: Jesse Jones (jesjones_at_[hidden])
Date: 2000-12-07 17:08:52

>In message <v03110701b654be52d4c8@[153.32.222.4]>, Jesse Jones
><jejones_at_[hidden]> writes
>>numeric_cast OTOH is very useful and not quite as trivial. I use something
>>like it in my own code. The only question I have is whether it should throw
>>or assert on failure. In my own code a failure almost always indicates a
>>programmer error so I'd prefer the assert.
>
>It should be a runtime failure rather than a debugging issue as there
>are many conversions that cannot be conveniently checked ahead of use --
>to do so would require near duplication of all the code that makes up
>numeric_cast :->

This is certainly true some of the time, but I think I'd quibble with the 
"many" part. :-) What I want is something easy to use that will let me 
efficiently cast between numeric types and do a bit of sanity checking to 
ensure that a bug hasn't slipped in. 

Casts where the value may not fit into the destination crop up much less 
often and I'd prefer to use a different mechanism to handle them. 

>One could also argue that there would be little point in having
>numeric_cast if it trapped only in debug mode. Might as well use
>static_cast and see if you get the right results in your unit tests --
>if not, you have a conversion bug! ;-)

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...

>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?

  -- Jesse