Re: dynamic_cast is ugly!
Owen Jacobson wrote:
<snip leaving only enough for context>
That is: I would not have made squares into a class of their own, but
rather expressed them via a predicate function that can be applied to
shapes. By not elevating the predicate to the class hierarchy,
querying and selection against the predicate is much more natural.
You could, for example, have
Owen,
I don't see what that gains you over dynamic_cast, and I can see it
could give problems.
Under the hood, I expect dynamic_cast<Square*>(someShapePtr) does
something like:
if (&(someShapePtr->vtbl) == &vbtl_Square)
{
return someShapePtr;
}
else
{
return 0;
}
This isn't a complicated bit of code.
Your function would have to be declared on Shape - and a similar
function for every derived class - and implemented to return false. Or
if it isn't a member, you have to implement a static function that takes
a pointer and somehow without dynamic_cast discovers if it's a Shape*.
This is a lot of (simple) code, if you have lots of classes, and because
it is so simple you won't concentrate when duplicating it for a new
class - and so you'll have two classes with the same "type".
What *would* be useful - and I've thought of doing it in our project -
is a virtual function on each class that returns an ID. You could then
switch on the ID. But once again, it's error prone, and has been
pointed out, what is the position for a multi-level inheritance
hierarchy - is a square a rectangle? A Rhombus? A Parallelogram? A
Quadrilateral? A Polygon? Or just a square?
Andy