Re: some questions about multiple inheritance
On Jul 1, 1:59 pm, Jess <w...@hotmail.com> wrote:
On Jun 30, 6:23 pm, James Kanze <james.ka...@gmail.com> wrote:
Thanks a lot! A related question that I forgot to ask is to prevent
derivation of a class, do we need to make the base class' constructors
private?
Unless the derivation is virtual, a further derived class
doesn't need to access the constructors of the base classes.
The classical solution to prevent further derivation is:
class ToBeBlocked ;
class BlockDerivation
{
private:
BlockDerivation() {}
friend class ToBeBlocked ;
}
class ToBeBlocked : private virtual BlockDerivation
{
// ...
} ;
Because the derivation is virtual, any class deriving from
ToBeBlocked must call the constructor of BlockDerivation from
its constructor. Which it can't.
In practice, I've found people deriving from classes they
shouldn't not to be a problem. If I really want to block
derivation, I'll explicitly document the fact that you're not
supposed to derive from this class, but typically, the semantics
of the class are such that it doesn't occur to anyone to derive
from it anyway. I've never bothered with anything like the
above, although a fair proportion of my classes are not designed
to be base classes.
[...]
Then every class (e.g. mostderived, a or b) that derives from it would
need to call "init()" in their initializer list? something like this?
More or less. The whole point, of course, is that only low
level derived classes would need to call it; further derived
classes can ignore it.
Do you mean only "a" and "b" need to call "init" while "mostderived"
doesn't have to?
I mean that by putting the real initialization in separate
function, you control who calls it. And who calls it depends
very much on the design semantics; there is no general rule.
It's also something that I would avoid if at all possible.
I'll try to avoid. On the other hand, it could happen that this init
function requires an input from a derived class to initialize a value
in vbase like this:
void init(int k){i = k;}
In this case, I'm not sure whether I should let "a", "b" or
"mostderived" call it. Suppose init requires an input from the most
derived class, then "init" should be called by "mostderived". However,
it seems "a" and "b" should also call "init" because they may have
been designed to be most derived classes of "vbase".
Exactly:-).
What you've just described is the design of the classical
iostream hierarchy. Both istream and ostream had two
constructors, one which took a streambuf*, and the other
(protected) which was a default constructor. The one which took
a streambuf* called init with the streambuf*; the other didn't,
supposing that a further derived class (e.g. iostream or
ofstream) would call init. (The standard iostream changed this,
and is designed so that init can be called multiple times.) A
class like ifstream might, for example, use the no-op
constructor of istream, and then call init itself, in order to
ensure that the filebuf it managed was completely constructed
before the base classes got a pointer to it. (There is still a
problem with the destructor, of course, and at least one
implementation of iostream I'm familiar with accesses the
streambuf in the destructor, which means that the destructor of
a derived class cannot destruct it.)
(The case of the iostream is a bit special, in that it was never
really well documented, and different implementations did
different things.)
--
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