Re: dynamic_cast is ugly!
On 15 mar, 17:42, c...@mailvault.com wrote:
On Mar 15, 3:54 am, James Kanze <james.ka...@gmail.com> wrote:
On 14 mar, 18:14, Jeff Schwab <j...@schwabcenter.com> wrote:
The suggestion that dynamic_case is necessary for passing
application-layer objects through lower level transport layers
is only marginally true. It is true that casts are used for
this purpose, but IME they are almost always of the
reinterpret_cast variety.
That very much depends on the transport layer, I would think.
They have to be: A general-purpose transport layer does not
know about the higher layer's object types.
And a specialize transport layer only knows a little. It
doesn't take much specialization to ensure that all of the
objects transported have a common base (i.e.
TransportableObject?), and are polymorphic.
I don't think there is anything gained from doing it that way
and with virtual functions there is probably some perf. hit.
There's a definite advantage in that you state up front which
objects are transportable. In many cases, such objects may have
to fulfill additional requirements as well. Deriving from a
common base allows some additional compile time checking.
As for the performance hit, be serious. You're going through an
extra layer; that will cost something in terms of runtime. More
than any virtual function call, anyway.
The transport mechanism is just sending bits over a wire,
Maybe, maybe not. There's not necessarily a wire; it's sending
objects between to components. There are many different types
of transport layer. (And even if there is a wire, many
protocols will have all transportable objects derive from some
common base type, or a small set of common base types.)
or at most doing some kind of byte-order or line-ending
conversion.
I think you're confusing the transport layer of OSI network
protocols (TCP, etc.) with the transport layer of OO design.
For dynamic_cast to be relevant, the transport mechanism has
to know about some base type used by the higher level. The
only case in which I could see this happening is if the
transport layer provides a base type with virtual methods,
maybe "serializable_object" or something, from which
higher-layer objects are supposed to derive. IMO, that kind
of design is completely upside-down and unnecessarily
invasive.
Why? If you want an object to be transportable, you say so. It
seems to me to be part of the basic principles of static type
checking.
The way I do it, you "say so" by adding Send/Receive function
prototypes to a class. The compiler will complain if it finds
implementations for those functions, but the class doesn't have
prototypes for them.
Which can work too, but is less sure than if the programmer
explicitly states that he implements the TransportableObject
contract. And at least in C++, doing this way means using
templates, with the resulting increase in coupling, code bloat
and explosion of compile times. (This would be partially
mitigated if your compiler supports export, but the code bloat
and some additional coupling is inevitable.)
You're transporting message objects between higher
level components which have connected to the transport layer.
You don't (and can't) transport just anything.
There has to be action from the programmer indicating what
types are going to be used in messages, but I don't think that
translates to inheritance being required. Using inheritance
like that seems just to get in the way and makes multiple
inheritance much more likely.
Inhertance remains the simplest and most efficient means of
specifying conformance to a contract. It does get in the way of
the programmer accidentally creating a class which conforms to
the superficial aspects (presence of such and such a function),
but being unaware of the actual contract, and not implementing
the desired semantics, yes.
And of course, multiple inheritance is a fact of life as soon as
you have static type checking. Big deal.
--
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