Re: dynamic_cast is ugly!
On Mar 9, 1:54 pm, "Daniel T." <danie...@earthlink.net> wrote:
James Kanze <james.ka...@gmail.com> wrote:
"Daniel T." <danie...@earthlink.net> wrote:
Ian Collins <ian-n...@hotmail.com> wrote:
A quick search of my active code base reveals two instances
of dynamic_cast, const and non-const conversion operations
in my DOM code!
It would be fun to sit down with you and see if we can't
connect the code that creates the objects to the code that
uses the objects, then remove those two dynamic_casts.
The question is more: do you want to. Should the code between
the provider and the consumer need to know about all of the
possible interfaces, as long as the provider and the consumer
are in agreement?
How do you know that the provider and the consumer are in
agreement? Or to put it another way, the fact that
dynamic_cast is in the code shows that the provider may very
well give the consumer something it can't consume (i.e., they
aren't in agreement.)
No, I don't think the transporting code should necessarily
know what it is transporting, but just like in the real world,
consumers shouldn't have to open the box after receiving the
item to see if it is really what they asked for either.
Agreed, but you can't really have it both ways. At least
dynamic_cast is like finding a detailed inventory at the top of
the box when you open it (or arguably, in an envelop pasted to
the outside of the box). I rather prefer it to the Smalltalk
solution where you have to ask about each method.
And you still haven't responded to Juta's question about what
you do when the transporter is managing several different
producer/consumer relationships, using different types, and the
order is significant. Keeping the actual objects in separate
containers, one for each type, means managing the order
externally. That's a lot of extra program logic just to avoid
one dynamic_cast at the consumer side.
In the end, of course, it's a trade off. Loosing the type, and
thus needing the dynamic_cast, means that what should have been
a compile time error becomes a runtime error. I've done enough
Java in the past (before Java had templates) to know what that
can cost. But in certain limited cases, it's manageable, and
increasing the code size of the transport mechanism by a factor
of 10, at the same time moving all of its code into templates
(and thus into the header files), isn't free either.
And of course, there are other cases where you might want it as
well: I've used in for version management in the past, and I'm
not alone. You might want to look at java.awt.LayoutManager2,
for example, and how it is used in some of the client classes.
(The name speaks for itself.) Obviously, support for existing
client code---which probably already derived from
java.awt.LayoutManager, and didn't provide the new functions,
but you don't want to limit yourself forever to the interface
that came up in your first design. In my case, I've often used
it in distributed systems---you can't expect 60,000 client
machines to all be updated at the same instant, so your code has
to handle both the older version, and the new, extended version.
(Obviously, the old clients won't ask for features that are only
present in the new version.)
And so on. The fact remains that I've found cases where
dynamic_cast was justified, in the sense that it was more cost
efficient than the alternatives. (With cost being measured in
program readability and maintainability, which basically end up
the equivalent of monitary cost in the end.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34