Problem with inheritance

[Victor Chew]

Can someone tell me why the following code doesn't work:

TestClass.cpp
-------------
class A
{
public:
virtual void read(wchar_t& ch) { read(&ch, 0, 1); }
virtual void read(wchar_t* buf, int off, int len) = 0;
};

class B : public virtual A
{
public:
virtual void read(wchar_t* buf, int off, int len) {}
};

int main(int argc, char* argv[])
{
wchar_t ch;
B myclass;
myclass.read(ch);
}

I have tried both gcc 2.96 and gcc 3.2. I get:

TestClass.cpp: In function `int main(int, char**)':
TestClass.cpp:21: no matching function for call to `B::read(wchar_t&)'
TestClass.cpp:14: candidates are: virtual void B::read(wchar_t*, int, int)

Shouldn't B have inherited read(wchar_t& ch) from A?

 

[Josephine Schafer]

Can someone tell me why the following code doesn't work:

TestClass.cpp
-------------
class A
{
public:
virtual void read(wchar_t& ch) { read(&ch, 0, 1); }
virtual void read(wchar_t* buf, int off, int len) = 0;
};

class B : public virtual A
{
public:
virtual void read(wchar_t* buf, int off, int len) {}
};

int main(int argc, char* argv[])
{
wchar_t ch;
B myclass;
myclass.read(ch);
}

I have tried both gcc 2.96 and gcc 3.2. I get:

TestClass.cpp: In function `int main(int, char**)':
TestClass.cpp:21: no matching function for call to `B::read(wchar_t&)'
TestClass.cpp:14: candidates are: virtual void B::read(wchar_t*, int,

int)

Shouldn't B have inherited read(wchar_t& ch) from A?

Your base class function virtual void read(wchar_t& ch) has been hidden by
the derived class
function virtual void read(wchar_t* buf, int off, int len).

 

[ES Kim]

Can someone tell me why the following code doesn't work:

TestClass.cpp
-------------
class A
{
public:
virtual void read(wchar_t& ch) { read(&ch, 0, 1); }
virtual void read(wchar_t* buf, int off, int len) = 0;
};

class B : public virtual A
{
public:
virtual void read(wchar_t* buf, int off, int len) {}
};

int main(int argc, char* argv[])
{
wchar_t ch;
B myclass;
myclass.read(ch);
}

I have tried both gcc 2.96 and gcc 3.2. I get:

TestClass.cpp: In function `int main(int, char**)':
TestClass.cpp:21: no matching function for call to `B::read(wchar_t&)'
TestClass.cpp:14: candidates are: virtual void B::read(wchar_t*, int, int)

Shouldn't B have inherited read(wchar_t& ch) from A?

B::read(wchar_t* buf, int off, int len) hides A::read(wchar_t& ch).
If you override an overloaded base class functions,
redefine full set of the functions.

 

[Alf P. Steinbach]

Can someone tell me why the following code doesn't work:

using A::read;

virtual void read(wchar_t* buf, int off, int len) {}
};

int main(int argc, char* argv[])
{
wchar_t ch;
B myclass;
myclass.read(ch);
}

I have tried both gcc 2.96 and gcc 3.2. I get:

TestClass.cpp: In function `int main(int, char**)':
TestClass.cpp:21: no matching function for call to `B::read(wchar_t&)'
TestClass.cpp:14: candidates are: virtual void B::read(wchar_t*, int, int)

Shouldn't B have inherited read(wchar_t& ch) from A?

It has, but without the 'using' it's hidden by the other read.
Now don't ask me _why_ someone thought that would be sensible.

 

[Victor Chew]

I don't get it. Isn't overriding based on method signatures? There is
clearly a difference between read(wchar_t&) and read(wchar_t*, int,
int)! Why can't I selectively override one of the methods from the base
class? What is the workaround?

Can someone tell me why the following code doesn't work:

using A::read;

virtual void read(wchar_t* buf, int off, int len) {}
};

int main(int argc, char* argv[])
{
wchar_t ch;
B myclass;
myclass.read(ch);
}

I have tried both gcc 2.96 and gcc 3.2. I get:

TestClass.cpp: In function `int main(int, char**)':
TestClass.cpp:21: no matching function for call to `B::read(wchar_t&)'
TestClass.cpp:14: candidates are: virtual void B::read(wchar_t*, int, int)

Shouldn't B have inherited read(wchar_t& ch) from A?

It has, but without the 'using' it's hidden by the other read.
Now don't ask me _why_ someone thought that would be sensible.

 

[Kevin Goodsell]

B::read(wchar_t* buf, int off, int len) hides A::read(wchar_t& ch).
If you override an overloaded base class functions,
redefine full set of the functions.

There is no overriding in this case. Also, redefining the entire set of
functions would be a pointless waste of time. A using declaration brings
the base class's overloads into scope nicely.

-Kevin

 

[Victor Chew]

Do you mind posting a short code segment showing me how to do this?

Thanks!

 

[John Harrison]

Do you mind posting a short code segment showing me how to do this?

Thanks!

class B : public virtual A
{
public:
virtual void read(wchar_t& ch) { A::read(ch); }
virtual void read(wchar_t* buf, int off, int len) {}
};

john

 

[Makis Papapanagiotou]

Hello,

You can use polymorphism in order to have the workaround solution.
Even though I wouldn't call it workaround, anyway...

A* myclass = new B;
myclass.read(ch);

Then everything will work properly, since late binding will take part, and
it will resolve the correct functions.

I don't get it. Isn't overriding based on method signatures? There is
clearly a difference between read(wchar_t&) and read(wchar_t*, int,
int)! Why can't I selectively override one of the methods from the base
class? What is the workaround?

Can someone tell me why the following code doesn't work:


TestClass.cpp
-------------
class A
{
public:
virtual void read(wchar_t& ch) { read(&ch, 0, 1); }
virtual void read(wchar_t* buf, int off, int len) = 0;
};

class B : public virtual A
{
public:

using A::read;

virtual void read(wchar_t* buf, int off, int len) {}
};

int main(int argc, char* argv[])
{
wchar_t ch;
B myclass;
myclass.read(ch);
}

I have tried both gcc 2.96 and gcc 3.2. I get:


TestClass.cpp: In function `int main(int, char**)':
TestClass.cpp:21: no matching function for call to `B::read(wchar_t&)'
TestClass.cpp:14: candidates are: virtual void B::read(wchar_t*, int, int)

Shouldn't B have inherited read(wchar_t& ch) from A?

It has, but without the 'using' it's hidden by the other read.
Now don't ask me _why_ someone thought that would be sensible.

 

[Kevin Goodsell]

Do you mind posting a short code segment showing me how to do this?

Thanks!

Please do not top-post. Re-read section 5 of the FAQ for posting
guidelines: http://www.parashift.com/c++-faq-lite/how-to-post.html

See Alf's reply for the example you requested.

-Kevin

 

[David White]

I don't get it. Isn't overriding based on method signatures? There is
clearly a difference between read(wchar_t&) and read(wchar_t*, int,
int)!

Please read all replies, such as my other one, if you see it there. It has a
link to a thread that explains the rule and why.

DW

 

[Alf P. Steinbach]

I don't get it. Isn't overriding based on method signatures? There is
clearly a difference between read(wchar_t&) and read(wchar_t*, int,
int)! Why can't I selectively override one of the methods from the base
class?

You can, and you just did.

It is just as static type B that one 'read' method is hidden. The other
is still there. E.g., you can cast it to A& and access the other 'read'.

David White here provided a URL to an earlier discussion where Russel
Hanneken provided a URL to an even earlier discussion where Chris Newton
tried to explain the original thinking, see [http://tinyurl.com/hlts].

What is the workaround?

'using', as shown in my first reply.

 

[Victor Chew]

Thanks for all your replies. I support Chris' comment that "I personally
regard this decision as unfortunate". If there is a perfect method
signature match in the base class which is not overridden in the
subclass, then it should simply be used. It's the principle of least
surprise.

I don't get it. Isn't overriding based on method signatures? There is
clearly a difference between read(wchar_t&) and read(wchar_t*, int,
int)! Why can't I selectively override one of the methods from the base
class?

You can, and you just did.

It is just as static type B that one 'read' method is hidden. The other
is still there. E.g., you can cast it to A& and access the other 'read'.

David White here provided a URL to an earlier discussion where Russel
Hanneken provided a URL to an even earlier discussion where Chris Newton
tried to explain the original thinking, see [http://tinyurl.com/hlts].

What is the workaround?

'using', as shown in my first reply.