Re: Inheriting the Wrong Constructor
On Aug 28, 6:11 am, Aalaa...@gmail.com wrote:
Read the FAQ. Prefer initialisation to assignment. Also,
it would seem that both constructors can be merged:
base(int x = 0, int y = 0, int z = 0) : x(x), y(y), z(z) {}
(and learn to omit the semicolons after function bodies).
This has nothing to do with inheriting constructors, and
everything with the rule that the _most derived class_ is
responsible for doing the initialisation of the virtual base
class[es].
'derived' has 'base' as virtual base class. That means it
*itself* is responsible for initialising the 'base'
subobject. That means, in turn, that in the initialiser
list of 'derived' there *will be* the call to 'base::base()'
(implicitly) if you don't specify explicitly what
constructor should be used. It is up to you to do it right,
the 'derived' object cannot delegate the responsibility to
any of its other base classes. So, you ought to write
derived() : base(1,2,3) {}
if you wanted the particular values to be passed to
'base::base'.
Thanks for the response but it's not the answer I was looking for.
It's the correct answer, however.
I don't want the answer I can't or my design in insufficient,
I want the answer do x y z to get around it.
But that's what Victor just gave you. Specify the initializers
in the most derived class.
So what is my reason to want the base class initialized by an
intermediate class rather than the derived class?
Which intermediate class? You can have several intermediate
classes deriving from the same instance of the virtual base.
A long, long time ago, John Skaller, Fergus Henderson and I
discussed the possibility of requiring the compiler to determing
the lowest common derived class for each virtual base, and
calling the constructor there. In the end, we didn't follow
through with a proposal, because it requires a lot more
complexity in the compiler, and the cases where you would want a
non empty virtual base (requiring an initializer) are
exceedingly rare. (Note, however, that there is an example of
such in the standard library: basic_ios<>. If worse comes to
worse, you can always use something like is used in the iostream
hierarchy. Be forewarned, however, that it can be extremely
tricky to make it work without undefined behavior is some
special cases.)
Because I'm using a policy based design. Let me give you a
more refined example, and again this is example code so no
need to worry about other critiques (I knew about all those
and I read the FAQ).
enum eShape {
circle,
triangle,
square
};
struct baseInteface
{
eShape shape;
baseInteface() {};
baseInteface(eShape shape) {base::shape = shape;};
//other stuff related to interface
};
namespace Triangle {
struct InitPolicy : public virtual baseInteface
{
InitPolicy() : baseInteface(triangle){};
};
struct SomeOtherPolicy {};
};
namespace Square {
struct InitPolicy : public virtual baseInteface
{
int height, width;
InitPolicy() : baseInteface(square){height = 0; width =
= 0;};
};
struct SomeOtherPolicy {};
};
template <
class shapePolicy,
class otherPolicy
struct Shape : public virtual shapePolicy, public virtual otherPolicy
{
Shape() : shapePolicy() {};
};
int main()
{
Shape<Triangle::InitPolicy, Triangle::SomeOtherPolicy> shape;
return 0;
}
I don't quite see why you need, or even want, virtual
inheritance here. All of your shapePolicy should inherit from
baseInteface (which is in fact BasicShapePolicy). And no other
classes should. So you really don't want virtual inheritance
here.
[...]
So any ideas on how to have some intermediate policy init a
base class without the derived class knowing about it?
In simple cases like this, you can simply use an init() member
function, calling it where ever you want.
--
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