On Jun 29, 2:05 pm, Jess <w...@hotmail.com> wrote:
On Jun 29, 6:07 pm, James Kanze <james.ka...@gmail.com> wrote:
Jess wrote:
On Jun 26, 11:02 pm, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
In this case, mostderived will call the constructors for a and
b. An important point to remember: every class type has a
constructor (if you don't provide one, the compiler does), and
that constructor will always be called, any time an instance of
the class exists, be it a sub-object or a complete object.
Given that, the pseudo code for what a compiler generates
automatically at the head of a constructor is more or less:
if ( this_is_most_derived_class ) {
call constructors for all virtual bases
}
call constructors for all direct non-virtual bases
call constructors for all objects
If you provide initializers in the initializer list of the
constructor, the compiler will use these when (and if) it calls
the constructor for the sub-object. The initializer list,
however, does not have any influence on when, or even if, the
constructor is called.
Many thanks. In Victor's example during the initialization of
"mostderived", the compiler has to call "a" and "b"'s constructors,
Are their default constructors called, with initializer list ignored?
In Victor's example, there is no initializer list to ignore, and
the only constructors are the default constructor and the copy
constructor. If he'd have written:
mostderived::mostderived()
: a( 1 )
, b( 2 )
{
}
the compiler would have complained, since there are no
corresponding constructors for a and b. But initializer list or
no, the constructor of mostderived will call the constructors of
a and of b, *after* having called the constructor of vbase.
What if their default constructors have non-empty bodies such as:
a::a(){i = 1;} //vbase.i = 1
b::b(){i = 2;} //vbase i = 2
Would the bodies be ignored too?
No. Nothing is being ignored. The constructors are being
called (or the call is being optimized out because the compiler
can see that it is a no-op).
If not, we would get conflicting
values of "i".
Not conflicting, successive. The order of initialization is
precisely specified: vbase::i will first be set to 42, by the
call to the constructor of vbase, then to 1, and then to 2, by
the constructors for a and for b. In that order.
Why don't you instrument the constructors, and try it?
[...]
Even worse, of course, is if a needs vbase to be initialized
with 1 to work, and b needs it to be initialized with 2. I
wouldn't go so far as Scott, and ban all data members, but I
would definitly ensure that any class from which I inherit
virtually has a default constructor; you don't want people
deriving some layers down to have to worry about what
initialization is needed.
What kind of default constructor? One with no initializer list and
with empty body?
Any kind of "default constructor". The standard says that a
default constructor is one that can be called with no arguments;
any constructor that can be called with no arguments fits the
bill.
Afterwards, it's up to you to decide what it should (or should
not) do.
In practice, most uses of virtual inheritance are of interfaces,
which naturally don't have any data, nor user defined
constructors, so there's no problem. Often, in mixin's, the
base class has no data either, or if it does, the base class
itself knows how to initialize it, so the default constructor is
all you need as well; if this is not the case, the mixin
hierarchy must be closed, so that there is no risk of someone
providing an incorrect initialization list.
To *close* a hierarchy, do we need to forbid all classes to inherit
from the currently most-derived-class?
More or less. It's not a formal term. I use it when a hierarchy
is more or less an implementation detail; all of the classes in
the hierarchy are designed and implemented at the same time, by
the same team, and the hierarchy is not designed for derivation
in client code. (Such cases occur more often than one might
think. In particular, I've never had a case of mixin's where
the hierarchy wasn't closed.)
If the virtual base
class does require an initializer, and one particular derived
class must provide it, then you have to provide a no-op default
constructor, and an initialize function which will be called by
that class. (This is how iostream handles the initialization of
std::basic_ios.)
Do you mean if "vbase" needs to have "i" initialized, then "vbase"
should provide a function to init "i" and "vbase" default constructor
is no-op? In other words, would vbase look something like:
class vbase{
public:
int i;
vbase(){}
void init(){i = 42;}
};
More or less. I'd set the variable to some "neutral" value in
the default constructor, just to avoid an uninitialized
variable, then provide an init() function that overrides it.
(But std::basic_ios doesn't do this. And calling the destructor
of a std::basic_ios before the init() function has been invoked
is undefined behavior.)
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.
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
"mostderived" call it. Suppose init requires an input from the most
derived class, then "init" should be called by "mostderived". However,