Boost logo

Boost :

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

>In message <v03110701b654be52d4c8@[]>, 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at