0

I'm learning C++ and in a school assignment I must use a diamond structure even if it is not totally correct.

class Book
{
    public:
        virtual int getPurchasePrice() const;
    protected:
        int m_purchasePrice;
};
class AdultBook: virtual public Book{} ;
class ChildrenBook: virtual public Book{} ;
class ComicBook: public AdultBook, public ChildrenBook {} ;

(I removed every methods and constructors to simplify)

Now, if I want to create a ComicBook and to know its purchasePrice, how can I do ? If I do getPurchasePrice() on a ComicBook I get the following error:

error: request for member 'getPurchasePrice' is ambiguous

I thought that putting virtual for ChildrenBook and AdultBook would solve the ambiguity ?

xenom
  • 377
  • 1
  • 5
  • 15
  • You've removed too much code from your example... and apparently vital semicolons, too. – Kerrek SB Nov 05 '12 at 12:44
  • I think it's the same problem as in: http://stackoverflow.com/questions/357307/c-how-to-call-a-parent-class-function-from-derived-class-function. – Guarita Nov 05 '12 at 12:45
  • [It should work](http://ideone.com/W8q50l) – Alok Save Nov 05 '12 at 12:46
  • Thanks for your answers, and sorry for semicolons. Well, in fact, there was a problem with virtual keywords missing.. For the constructor of ComicBook, I'm obliged to call constructor of Book, AdultBook and ChildBook, right ? If yes, it seems to work now. – xenom Nov 05 '12 at 13:01

2 Answers2

2

You use either

obj->AdultBook::getPurchasePrice();

or

obj->ChildrenBook::getPurchasePrice();

or

obj->Book::getPurchasePrice();

For obj of type ComicBook

EDIT FOR Emilio Garavaglia

Lets assume that you have not redefined getPurchasePrice for adult and childrens book, you could have this

Key A - Adult book, C - Childrens book, CB - Comic Book, B - Book

enter image description here

Ed Heal
  • 59,252
  • 17
  • 87
  • 127
  • What the purpose of inheritance of virtual functions? If you have to know the type of an object, just use plain function instead of virtual! – Emilio Garavaglia Nov 05 '12 at 13:04
  • er .... no ... you've completely misunderstood my question. (I know what virtual inheritance is ...). My point was a PROOF BY ABSURD about the fact that -if you have to know the type of an object before placing a call- there is no clue in use OOP at all (since no run-time decision are taken). The problem, here, is why the OP did that design. If it makes sense (fora whatever reason) it has to work without explicit calls from the client code (client code = code that USES the classes, not that defines them). If it doesn't make sense, then that's not a proper hierarchy for that kind of problem. – Emilio Garavaglia Nov 05 '12 at 15:59
  • Consider that the adults book is in hard cover whilst the childs book is in paper back. Then the bottom diagram might apply. But say if the book class stores where in the bookshop the location of the book is then the top diagram would apply. Persoanlly I am against multiple inheritance. It usually causes more problems that it solves and there are a variety or techniques to get over this. – Ed Heal Nov 05 '12 at 16:16
2

This is most likely due to the fact that getPurchasePrice is implemented in both AdultBook and ChildrenBook, but not in ComicBook, that inherits two different implementations for a same virtual function.

You have to override getPurchasePrice for ComicBook as well, and eventually implement with a call to one of the two bases's.

Emilio Garavaglia
  • 20,229
  • 2
  • 46
  • 63