Boost logo

Boost :

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

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

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