Moes wrote:
[ ... ]
Is it that uncommon to have a function take a base class pointer, and
treat the object pointed to by that pointer as one of a number of
possible derived types (discovered via an enum "type" member of the
base class which is guaranteed to be set correctly depending on which
derived type the object is)?
A "switch on type" is one of the classic signs of a design that
_probably_ has problems. One of the most basic ideas of virtual
functions is to allow you to avoid worrying about the specific type,
and instead treat all the objects the same way, with each one
implementing that function as needed.
struct Car{ [ ... ]
struct Toyota : public Car{ [...]
struct Honda : public Car{
[ ... ]
The question where would be "what sort of thing is there about a Honda
that's _fundamentally_ different from a Toyota?" The answer is usually
"not much" -- differences should normally be determined by function,
not something like brand.
There are times it makes sense to do something vaguely like this -- for
example, if you had:
struct car
struct SUV_4WD : public car
it might make sense for SUV_4WD to have a "lock_front_hubs" member
that's missing from a generic car, and you might have code like:
if (car.stuck()) {
SUV_4WD *p = dynamic_cast<SUV_4WD &>(car);
if (NULL != p) {
p.lock_front_hubs();
p.retry_moving();
}
}
OTOH, while there may be some excuse for this, it's still really
working at a relatively low level of abstraction, and we can do better
-- it would usually be better to have a virtual function
"maximize_traction". In the base class it would be a NOP, but in the
4WD class it would lock the hubs (and possibly shift the transmission
to low range as well).
To answer your question more directly, no it's not that uncommon -- but
it should be!