Re: some abstract base class dont need vtbl?
petke wrote:
[...]
Maybe this real world example will show this better. (This was
in java but that does not really matter.)
I think it does, actually.
In a project we where making soundengines for different mobile
phones. The phones where incompatible. Running the wrong
soundengine on the wrong phone would make it crash. We built
our application differently for all these incompatible phones.
We used preprocessing to specify what actual soundengine we
wanted to use. For this to work we needed to make sure that
the different soundengines really where syntactically
interchangeable (had the same interface). This was done by
having all soundengines inherit from the same abstract base
class; this was done just to lock the interface down. Speed
and size was of concern, and there was no need for any runtime
polymorphic behavior. Changing the soundengine would be done
by recompiling. Surely that makes sense? If you need me to I
can go into the details.
It does. But as you said, the project was in Java, where this
is the only solution. There's an old saying along the lines of
"if all you have is a hammer, everything looks like a nail." In
Java, all you have is inheritance and runtime polymorphism, so
everything uses inheritance and runtime polymorphism. In C++,
for this sort of problem, the usual solution is link time
polymorphism: you write a header file with the class definition
(using the compilation firewall idiom if necessary, and of
course, no inlne functions), and a different source file for
each implementation. You choose the correct object file for the
header at link time.
If the use of the compilation firewall idiom and the lack of
inline functions cause unacceptable performance problems, it is
also possible to include the device dependant declarations in a
separate header, which is present in a device dependant
directory, chosen by means of a -I option when the code is
compiled. In this case, of course, you have to recompile all of
the client code for each device, rather than just choosing at
link time.
That was one example. Another would be a game that could be
compiled eighter with OpenGL or DirectX etc.
I've not enough experience with these to be sure, but I imagine
that most of the time, a technique similar to the above would be
used. (Under X, it is usual to compile to a common graphic
interface, then link dynamically against different
implementations, using e.g. Motif, the Athena widgets, etc.,
depending on variable in the user's environment. Again, link
time polymorphism, although in this case, the link is deferred
until program start-up.)
I am sure there are others areas where this would be of use. I
have a feeling it would be useful in network programming also.
The client and server are separate and do not share any code.
However they both have to know the protocol/interface they
communicate thru. I believe this could be communicated and
locked down by both sides using the same abstract base class.
I'm not sure what you're envisaging, but for all but the
simplest protocols, the code for the serializable types will
normally be generated automatically from a higher level
specification. As for the rest of the protocol, it's just a
library; there's never any dynamic polymorphism involved.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]