From: Jesse Jones (jesjones_at_[hidden])
Date: 2000-12-07 23:29:40
>Jesse Jones wrote:
>> >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 better because it wasn't supposed to be a 'dynamic_cast' in the first
>place. It should be
>derived = static_cast<Derived*>(base);
>because you use 'polymorphic_downcast' only then you KNOW that base actually
>points to Derived. But you don't want to deal with a mess you'll get in case
>if someone make changes that break your code, so you use
>'polymorphic_downcast' to trap that situation.
Right, and I'm saying that you can nearly always simply use dynamic_cast
and do the assert yourself.
>> 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.
>It's not about micro-optimization, it's about showing the intent of code in a
>less amount of lines and in the most expressive way. 'polymorphic_downcast'
>states that cast to Derived* should always succeed BY DEFINITION, point.
Does it really show the intent? I don't know about you, but I have real
problems remembering the difference between polymorphic_cast and
polymorphic_downcast. I suspect most users won't have a clue what either
one means. It's true that they can look up the definition, but this seems
like an unneccesary burden to place on readers.
>/**/ }". Also, speaking about expressiveness, consider passing the result of
>the cast to a function:
>Derived* derived = dynamic_cast<Derived*>(base);
>assert(derived != NULL);
>I certainly prefer the last form.
I would put the assert in foo. :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk