Re: some abstract base class dont need vtbl?
petke wrote:
I don't understand. How can you enforce a common interface on a
family of classes by deriving them from an empty base class? If you
want classes to be related via runtime polymorphism, you need
virtual functions, otherwise you don't.
Runtime polymorphism isn't what im looking for.
Then why do you need a common base class. I'm having more and more
difficulty understanding what you are asking for.
I think this other type of inheritance is the most useful type of all.
Just to make clear what I mean. In java the keyword interface is
heavily used.
Not in well written Java. When I worked in Java, we found that we
almost always needed an abstract base class to define a conceptual
interface, and not what Java calls an interface. (This may have
changed
since, of course. Java's still pretty unstable.)
In c++ we do it by abstract base classes. By publicly inheriting these
kinds of classes we only inherit the interface, and no implementation.
Right. That's what polymorphism is all about. Programming against an
interface, without knowing what's behind it.
(To reuse any implementation it is considered better to use
aggregation or protected inheritance anyway). We use objects thru
their abstract interface and we only commit to the smallest interface
we can. As in;
//Pseudo code..
Class Phil : public WorkerABI, public BeerDrinkerABI {...}
Class Joe : public WorkerABI, public BeerDrinkerABI {...}
...
If(!weekend) {
WorkerAbstarctBase aPtr1 * = new Phil();
aPtr1.work();
aPtr1 = new Joe();
aPtr1.work();
}else {
BeerDrinkerAbstarctBase aPtr1 * = GetRandomBeerDrinker();
aPtr1.drink();
}
I'm not sure I understand this at all. What's the relationship between
WorkerABI and WorkerAbstarctBase, for example?
Well that might be a bad example but I need it that to answer your
question: "How can you enforce a common interface on a family of
classes by deriving them from an empty base class"
You've lost me once more. In C++, an "interface" is never empty. Even
a tagging interface will have a virtual destructor.
Well any class (Joe or Phil) that want to belong to the family of
workers or beer drinkers has to publicly derive from the abstract base
WorkerABI or BeerDrinkerABI. If it didn't the above code would not
compile. That's because I use the object by an abstract base class
pointer. That is how I can enforce the interface of object of the same
family.
I hope that made some sense.
Not much. If WorkerABI is empty, then you still have to somehow find
out whether you have a Joe or a Phil, and use static_cast to get a
pointer to which ever one you want. If WorkerABI is just a tagging
interface, it would still be preferable to give it a virtual
destructor,
and use dynamic_cast to get the correct type. And tagging interfaces
are (or should be) fairly exceptional; in the normal case, WorkerABI
will have a whole set of pure virtual functions, and the user code will
only use these, and never know or care what the actual type is.
--
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! ]