Re: [boost] Formal Review: Boost Cast Library

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

>
>----- Original Message -----
>From: "Jesse Jones" <jejones_at_[hidden]>
>
>> I looked at cast.hpp and it seems to work OK with CW 6 on a Mac (although
>> the test spewed out more verbiage than seems neccesary and there's that
>> weird line that has the "see if compiler generates warning" comment).
>>
>> polymorphic_cast and polymorphic_downcast are rather trivial and seem to
>> mostly be rarely useful so I'm inclined to say that they should not be
>part
>> of boost.
>
>I hope we don't make that decision, as it would require me and my colleagues
>to change quite a lot of working code which depends on polymorphic_downcast.

If they don't make it into boost there's nothing preventing you from 
defining them yourself...

>I hope that is sufficient to speak for the utility of these functions. As to
>triviality, the same could be said for std::pair<>. Sometimes a trivial
>construct has great advantages in expressive power.

Sure, but I think these two functions impair rather than enhance 
readability. How is:
   derived = polymorphic_downcast <Derived*>(base); 
better than
   derived = dynamic_cast<Derived*>(base); 
   assert(derived != NULL);

It's really only better because polymorphic_downcast doesn't do a 
dynamic_cast in release. But I don't think this sort of 
micro-optimization merits yet another cast operator.

I'm having a hard time seeing any use for polymorphic_cast other than 
throwing an exception instead of crashing. There's some merit in this, 
but I would hope that testing would uncover such a fundamental error.

>> 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.
>
>That's an interesting point of view. Currently, the boost python library
>depends on having a throwing version. The asserting version can be built on
>the throwing version, but not vice-versa, so I hope we'll keep the one that
>throws.

The python library seems like it might be a bit of a special case. I use 
numeric casts quite a bit to convert between signed and unsigned ints (I 
have CW's errors cranked up so it complains about these). I also use them 
quite a bit in my Mac code to convert ints to shorts when calling the 
MacOS GUI functions. In both these cases the cast should always succeed 
so I want to assert in debug and merely do a static_cast in release. 
Throwing an exception OTOH is much more than I need.

  -- Jesse