Inheritance Problem (MSVC 6)

[Hans-Dieter Dreier]

Hi NG,

I have an inheritance like this:

class a_interface
{
virtual bool x() = 0;
};

class a_version_1 : public a_interface
{
virtual bool x() {return true;}
}

class a_version_2: public a_interface
{
virtual bool x() {return false;}
}

class b_interface: public a_interface
{
};

class b_derived: public a_interface, public a_version_1
{
};

class b_interface is never instantiated, only its derived classes are (there
are lots of them, some need a_version1, some a_version2).
When I try to create an instance of b_derived, I get the error "pure virtual
function not defined". Why doesn't it take bool x() from a_version_1?
Is this a bug in Visual Studio 6?
What can I do about it, if I need to access a_interface from within
b_interface, other than re-implementing a_version_x in every derived class?

TIA
Hans-Dieter Dreier

[Victor Bazarov]

Hans-Dieter Dreier wrote:

Hi NG,

I have an inheritance like this:

class a_interface
{
virtual bool x() = 0;
};

class a_version_1 : public a_interface
{
virtual bool x() {return true;}
}

class a_version_2: public a_interface
{
virtual bool x() {return false;}
}

class b_interface: public a_interface
{
};

class b_derived: public a_interface, public a_version_1

I think you meant

class b_derived: public b_interface, public a_version_1

{
};

class b_interface is never instantiated, only its derived classes are
(there are lots of them, some need a_version1, some a_version2).
When I try to create an instance of b_derived, I get the error "pure
virtual function not defined". Why doesn't it take bool x() from
a_version_1?
Is this a bug in Visual Studio 6?

No.

What can I do about it, if I need to access a_interface from within
b_interface, other than re-implementing a_version_x in every derived
class?

First of all, your 'a_interface' should probably be derived from
*virtually*. Have you tried that?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Hans-Dieter Dreier]

----- Original Message -----
From: "Victor Bazarov" <v.********@comAcast.net>
Newsgroups: comp.lang.c++
Sent: Friday, June 08, 2007 7:35 PM
Subject: Re: Inheritance Problem (MSVC 6)

class b_derived: public a_interface, public a_version_1

I think you meant

class b_derived: public b_interface, public a_version_1

Sure. Sorry for the typo.

What can I do about it, if I need to access a_interface from within
b_interface, other than re-implementing a_version_x in every derived
class?

First of all, your 'a_interface' should probably be derived from
*virtually*. Have you tried that?

Yes. No difference. AFAIK the purpose of virtual inheritance is just to
avoid duplication of data members, so that's no surprise to me.

Do you know how the C++ standard would handle such a situation?

[Victor Bazarov]

Hans-Dieter Dreier wrote:

----- Original Message -----
From: "Victor Bazarov" <v.********@comAcast.net>
Newsgroups: comp.lang.c++
Sent: Friday, June 08, 2007 7:35 PM
Subject: Re: Inheritance Problem (MSVC 6)

>>class b_derived: public a_interface, public a_version_1

I think you meant

class b_derived: public b_interface, public a_version_1

Sure. Sorry for the typo.

>>What can I do about it, if I need to access a_interface from within
b_interface, other than re-implementing a_version_x in every derived
class?

First of all, your 'a_interface' should probably be derived from
*virtually*. Have you tried that?

Yes. No difference. AFAIK the purpose of virtual inheritance is just
to avoid duplication of data members, so that's no surprise to me.

Do you know how the C++ standard would handle such a situation?

In order to make a class non-abstract all pure virtual functions it
inherits have to have final non-pure overriders. Overriding only
works *directly* in the hierarchy. You cannot expect your class'
uncle to override your class' father's pure functions.

struct ABC {
virtual void foo() = 0;
};

struct CC : ABC {
void foo() {}
};

struct YAABC : ABC {
// here you have one inherited virtual function
// virtual void foo() = 0;
// and it's pure
};

struct MYCC : YAABC, CC {
// here you have two inherited functions, one
// comes from YAABC and its pure and the other
// comes from CC, and it's OK.
};

The language cannot decide for you what MYCC::foo should do. You
actually have two virtual functions inherited, and one of them is
pure that does not have the final overrider. See subclause 10.3
for the actual rules involved. Paragraph 10 shows the situation
similar to yours (no unambiguous final overrider).

To disambiguate the behaviour you have to introduce the final
overrider into 'MYCC'. What it does is up to you, but the most
acceptable way is

struct MYCC : YAABC, CC {
void foo() { return CC::foo(); }
};

That cannot be done automatically, it would generate more problems
than it would solve.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Hans-Dieter Dreier]

"Victor Bazarov" <v.********@comAcast.netschrieb im Newsbeitrag
news:f4**********@news.datemas.de...

[snip]

To disambiguate the behaviour you have to introduce the final
overrider into 'MYCC'. What it does is up to you, but the most
acceptable way is

struct MYCC : YAABC, CC {
void foo() { return CC::foo(); }
};

That cannot be done automatically, it would generate more problems
than it would solve.

I already suspected that.
Maybe I'll have to resort to a (shudder!) preprocessor macro to save me a
lot of typing.

Thanks a lot for the quick response anyway !
Hans-Dieter Dreier

[Victor Bazarov]

Hans-Dieter Dreier wrote:

"Victor Bazarov" <v.********@comAcast.netschrieb im Newsbeitrag
news:f4**********@news.datemas.de...

[snip]

>To disambiguate the behaviour you have to introduce the final
overrider into 'MYCC'. What it does is up to you, but the most
acceptable way is

struct MYCC : YAABC, CC {
void foo() { return CC::foo(); }
};

That cannot be done automatically, it would generate more problems
than it would solve.

I already suspected that.
Maybe I'll have to resort to a (shudder!) preprocessor macro to save
me a lot of typing.

I doubt that it would actually save you anything. It would definitely
make things more unclear.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[James Kanze]

On Jun 8, 8:02 pm, "Victor Bazarov" <[e-mail]:

Hans-Dieter Dreier wrote:

In order to make a class non-abstract all pure virtual functions it
inherits have to have final non-pure overriders. Overriding only
works *directly* in the hierarchy. You cannot expect your class'
uncle to override your class' father's pure functions.

struct ABC {
virtual void foo() = 0;
};

struct CC : ABC {
void foo() {}
};

struct YAABC : ABC {
// here you have one inherited virtual function
// virtual void foo() = 0;
// and it's pure
};

struct MYCC : YAABC, CC {
// here you have two inherited functions, one
// comes from YAABC and its pure and the other
// comes from CC, and it's OK.
};

The language cannot decide for you what MYCC::foo should do. You
actually have two virtual functions inherited, and one of them is
pure that does not have the final overrider. See subclause 10.3
for the actual rules involved. Paragraph 10 shows the situation
similar to yours (no unambiguous final overrider).

To disambiguate the behaviour you have to introduce the final
overrider into 'MYCC'. What it does is up to you, but the most
acceptable way is

struct MYCC : YAABC, CC {
void foo() { return CC::foo(); }
};

That cannot be done automatically, it would generate more problems
than it would solve.

The more classical solution, I think, would be to use virtual
inheritance. If there is only one instance of ABC (because CC
and YAABC both inherit virtually from it), then the function is
implemented, and there is no problem.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Victor Bazarov]

James Kanze wrote:

On Jun 8, 8:02 pm, "Victor Bazarov" <[e-mail]:

>Hans-Dieter Dreier wrote:

>In order to make a class non-abstract all pure virtual functions it
inherits have to have final non-pure overriders. Overriding only
works *directly* in the hierarchy. You cannot expect your class'
uncle to override your class' father's pure functions.

> struct ABC {
virtual void foo() = 0;
};

> struct CC : ABC {
void foo() {}
};

> struct YAABC : ABC {
// here you have one inherited virtual function
// virtual void foo() = 0;
// and it's pure
};

> struct MYCC : YAABC, CC {
// here you have two inherited functions, one
// comes from YAABC and its pure and the other
// comes from CC, and it's OK.
};

>The language cannot decide for you what MYCC::foo should do. You
actually have two virtual functions inherited, and one of them is
pure that does not have the final overrider. See subclause 10.3
for the actual rules involved. Paragraph 10 shows the situation
similar to yours (no unambiguous final overrider).

>To disambiguate the behaviour you have to introduce the final
overrider into 'MYCC'. What it does is up to you, but the most
acceptable way is

> struct MYCC : YAABC, CC {
void foo() { return CC::foo(); }
};

>That cannot be done automatically, it would generate more problems
than it would solve.

The more classical solution, I think, would be to use virtual
inheritance. If there is only one instance of ABC (because CC
and YAABC both inherit virtually from it), then the function is
implemented, and there is no problem.

That's what I suggested first. For some reason the OP replied
that it didn't work. Old compiler, maybe?...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[James Kanze]

On Jun 9, 1:54 am, "Victor Bazarov" <[e-mail]:

James Kanze wrote:

On Jun 8, 8:02 pm, "Victor Bazarov" <[e-mail]:

Hans-Dieter Dreier wrote:

[...]

The more classical solution, I think, would be to use virtual
inheritance. If there is only one instance of ABC (because CC
and YAABC both inherit virtually from it), then the function is
implemented, and there is no problem.

That's what I suggested first. For some reason the OP replied
that it didn't work. Old compiler, maybe?...

Pre-CFront 2.1? More likely he made a mistake somewhere (maybe
only declared one of the inheritances virtual).

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]