468,747 Members | 1,700 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,747 developers. It's quick & easy.

Help: virtual inheritance, non-default constructor

When compiling the following program, I get an error on the line specified:
The base class "B" cannot be initialized because it does not have a default
constructor.

If I remove the "virtual" inheritance of B (so that it uses plain
inheritance), it compiles fine. It also compiles if I invoke the
constructor for B explicitly, as shown in the comment after the error. I'm
not aware of any reason that virtual inheritance should be special in this
respect. What's wrong?

class B
{
public:
B(int){}
};

class C : virtual public B
{
public:
C():B(1){}
};

class D : public C
{
public:
D(){} // error here
// D():B(1){} - this however compiles OK
};

int main()
{
return 0;
}
Jul 19 '05 #1
10 6943

"jeffc" <no****@nowhere.com> wrote in message news:3f********@news1.prserv.net...
When compiling the following program, I get an error on the line specified:
The base class "B" cannot be initialized because it does not have a default
constructor.

The initialization of a virtual base is done by the most derived object.
Your class D must provide the necessary initializers for the virtual base
B. The virtual base is initialized just once and before any of the non-virtual
bases are initialized.
Jul 19 '05 #2

"jeffc" <no****@nowhere.com> wrote in message
news:3f********@news1.prserv.net...
When compiling the following program, I get an error on the line specified: The base class "B" cannot be initialized because it does not have a default constructor.

If I remove the "virtual" inheritance of B (so that it uses plain
inheritance), it compiles fine. It also compiles if I invoke the
constructor for B explicitly, as shown in the comment after the error. I'm not aware of any reason that virtual inheritance should be special in this
respect. What's wrong?


I finally found a reference to this problem in "Effective C++". Meyers
states that "arguments are specified in the member initialization lists of
the classes *most derived* from the base. As a result, the class
initializing a virtual base may be arbitrarily far from it in the
inheritance graph, and furthermore, the class performing the initialization
can change as new classes are added to the hierarchy."

So, 3 questions:
1) why is this so?
2) is he implying that once a new class is added to the hierarchy, the
initialization must be performed there *instead of* in the base class?
(because this seems inconsistent with what happens in the code I posted -
both the derived class and base class initialize the virtual base.
3) why does this make any difference at all, since I'm not even using
multiple inheritance? Is it merely a compiler implementation issue?
Jul 19 '05 #3
jeffc wrote:
"jeffc" <no****@nowhere.com> wrote in message
news:3f********@news1.prserv.net...
When compiling the following program, I get an error on the line


specified:
The base class "B" cannot be initialized because it does not have a


default
constructor.

If I remove the "virtual" inheritance of B (so that it uses plain
inheritance), it compiles fine. It also compiles if I invoke the
constructor for B explicitly, as shown in the comment after the error.


I'm
not aware of any reason that virtual inheritance should be special in this
respect. What's wrong?

I finally found a reference to this problem in "Effective C++". Meyers
states that "arguments are specified in the member initialization lists of
the classes *most derived* from the base. As a result, the class
initializing a virtual base may be arbitrarily far from it in the
inheritance graph, and furthermore, the class performing the initialization
can change as new classes are added to the hierarchy."

So, 3 questions:
1) why is this so?
2) is he implying that once a new class is added to the hierarchy, the
initialization must be performed there *instead of* in the base class?
(because this seems inconsistent with what happens in the code I posted -
both the derived class and base class initialize the virtual base.
3) why does this make any difference at all, since I'm not even using
multiple inheritance? Is it merely a compiler implementation issue?


IIRC in my copy of Meyer's he starts of with "Just when you
thought you understood it, they change the rules!" or some
such. A page onwards I believe he gives an explaination of why.

Jul 19 '05 #4

"lilburne" <li******@godzilla.net> wrote in message
news:bo*************@ID-203936.news.uni-berlin.de...

So, 3 questions:
1) why is this so?
2) is he implying that once a new class is added to the hierarchy, the
initialization must be performed there *instead of* in the base class?
(because this seems inconsistent with what happens in the code I posted - both the derived class and base class initialize the virtual base.
3) why does this make any difference at all, since I'm not even using
multiple inheritance? Is it merely a compiler implementation issue?


IIRC in my copy of Meyer's he starts of with "Just when you
thought you understood it, they change the rules!" or some
such. A page onwards I believe he gives an explaination of why.


He does say that - in the next subsection (which deals with virtual
functions). But I didn't see further explanation.
Jul 19 '05 #5

"Ron Natalie" <ro*@sensor.com> wrote in message
news:3f*********************@news.newshosting.com. ..

"jeffc" <no****@nowhere.com> wrote in message news:3f********@news1.prserv.net...
When compiling the following program, I get an error on the line specified: The base class "B" cannot be initialized because it does not have a default constructor.

The initialization of a virtual base is done by the most derived object.
Your class D must provide the necessary initializers for the virtual base
B. The virtual base is initialized just once and before any of the

non-virtual bases are initialized.


I'm having another problem (I get a link error when I define a constructor -
it says some symbol is defined more than once), but I can't narrow it down
enough to post it. Anyway, in our code, there is virtual inheritance of the
a class, but no multiple inheritance. Other than designing for the fact
that someone *might* use multiple inheritance, is there any reason to use
virtual inheritance?
Jul 19 '05 #6

"jeffc" <no****@nowhere.com> wrote in message news:3f********@news1.prserv.net...
I'm having another problem (I get a link error when I define a constructor -
it says some symbol is defined more than once), but I can't narrow it down
enough to post it.


Do you have it not-inlined but still in the include file? That will cause the problem.
Jul 19 '05 #7
jeffc wrote:

I'm having another problem (I get a link error when I define a constructor -
it says some symbol is defined more than once), but I can't narrow it down
enough to post it. Anyway, in our code, there is virtual inheritance of the
a class, but no multiple inheritance. Other than designing for the fact
that someone *might* use multiple inheritance, is there any reason to use
virtual inheritance?


Well you only 'need' virtual inheritance if you have
multiple inheritance of classes derived from a common base
and you only want one copy of the base. It brings with it a
whole host of complications, which you're probably best off
avoiding if at all possible. You'd be unwise to add it just
on the off-chance. Stuff will get complicated enough anyway
so why add to it needlessly?
Jul 19 '05 #8

"Ron Natalie" <ro*@sensor.com> wrote in message
news:3f*********************@news.newshosting.com. ..

"jeffc" <no****@nowhere.com> wrote in message news:3f********@news1.prserv.net...
I'm having another problem (I get a link error when I define a constructor - it says some symbol is defined more than once), but I can't narrow it down enough to post it.


Do you have it not-inlined but still in the include file? That will

cause the problem.

Sorry, I said "constructor" but I meant to say "destructor". I do not have
anything defined in the include file. I realize it's not enough to go on,
but until and unless I can narrow down the problem, posting the code isn't
really an option.
Jul 19 '05 #9

"lilburne" <li******@godzilla.net> wrote in message
news:bo*************@ID-203936.news.uni-berlin.de...

Well you only 'need' virtual inheritance if you have
multiple inheritance of classes derived from a common base
and you only want one copy of the base. It brings with it a
whole host of complications, which you're probably best off
avoiding if at all possible. You'd be unwise to add it just
on the off-chance. Stuff will get complicated enough anyway
so why add to it needlessly?


Yes, well that is true. The problem is that it's already there in the code
I'm customizing, and I really don't know why.
Jul 19 '05 #10
jeffc wrote:
"lilburne" <li******@godzilla.net> wrote in message
news:bo*************@ID-203936.news.uni-berlin.de...
Well you only 'need' virtual inheritance if you have
multiple inheritance of classes derived from a common base
and you only want one copy of the base. It brings with it a
whole host of complications, which you're probably best off
avoiding if at all possible. You'd be unwise to add it just
on the off-chance. Stuff will get complicated enough anyway
so why add to it needlessly?

Yes, well that is true. The problem is that it's already there in the code
I'm customizing, and I really don't know why.


Ask the class author, or check back through the classes
implementation history. What other classes inherit from it,
and how do they resolve the problems? Was the virtual really
intended or was someone just trying to impress? Perhaps you
can get permission to remove it.
Jul 19 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Jeff Greenberg | last post: by
4 posts views Thread by JKop | last post: by
4 posts views Thread by aap | last post: by
3 posts views Thread by Imre | last post: by
9 posts views Thread by Chrissy | last post: by
23 posts views Thread by Dave Rahardja | last post: by
12 posts views Thread by Massimo | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.