Re: dynamic_cast is ugly!

From:

"Daniel T." <daniel_t@earthlink.net>

Newsgroups:

comp.lang.c++

Date:

Sat, 08 Mar 2008 09:18:02 -0500

Message-ID:

<daniel_t-BA8976.09180108032008@earthlink.vsrv-sjc.supernews.net>

Juha Nieminen <nospam@thanks.invalid> wrote:

Daniel T. wrote:

Juha Nieminen <nospam@thanks.invalid> wrote:

Jeff Schwab wrote:

What if [you are forced to work with classes that are designed
poorly?]

That's what dynamic_cast is there for.

How is it a poor design that a collection has object in a certain
order (in a context where this order is relevant)?

Why would you even ask the question? Nobody has claimed that the above
was poor design.

One good example of a collection where order is relevant is a
collection of screen elements: The order of these screen elements
in the collection is the order in which they are drawn on screen,
which determines which elements are drawn on top of the others.

I can't even begin to imagine how you could easily determine the
drawing order of screen primitives if each primitive was in a
type-specific container. You would need an additional container
which contains the pointers in the order in which the primitives
should be drawn, duplicating the amount of data stored and making
the whole system quite a lot more complicated to manage (for
example swapping the drawing order of two given primitives becomes
needlessly complicated).

Since I work with such issues on a regular basis, and I never use
dynamic_cast, let me assure you that you can keep track of drawing order
without throwing away type information. How you go about doing it
depends on the design goals.

Trying to go backwards along an inheritance arrow is as poor design as
trying to go backwards along an association arrow. The only difference
is that with the former, the language provides a primitive to allow it,
while with the latter, it doesn't. Just because the primitive is
provided, doesn't mean it should be used willy nilly.