ernesto wrote:
Hi everybody I have the following class declarations:
class Interface
{
public:
virtual char* getName() const = 0;
};
class BaseClass : public Interface
{
public:
BaseClass() { }
virtual char* getName() const { return name; }
private:
char* name;
use std::string instead, name can be a pointer to nothing, to a single
character or to an array of characters and maybe even to a
null-terminated sequence of characters. Why deal with the ambiguity?
Why deal with the uncertainty of a pointer?
};
class Comparable : public Interface
{
public:
virtual int compare(Interface* value) const = 0;
};
class Person : public BaseClass, public Comparable
{
public:
Person() { }
virtual int compare(Interface* value) const { return 0; }
};
Everything looks ok (for me), but when I try to:
Person* p = new Person();
the compiler (g++) says to me that I cannot allocate an object of type
Person because it has virtual abstract methods.
Yes, thats right. both Interface::getName() and
Comparable::compare(...) are pure virtual. The code you wrote does not
satisfy that requirement since Comparable is not "using" the same
Interface as Baseclass.
>
I think that the compiler cannot figure out that the implementation of
getName() [defined in BaseClass and in Comparable] has already provided
by BaseClass.
Wrong determination. The way you wrote the code, there are 2 distinct
interfaces. And thats the problem. Read up on the dreaded diamond and
virtual inheritance.
http://www.parashift.com/c++-faq-lit...heritance.html
section 25.8, 25.9 and 25.10
Unlike Java, were creating garbage is perfectly acceptable, C++ holds
you responsible for all allocations and deallocations. So try not using
pointers and new until you understand the implications.
And don't listen to people that suggest that its ok to leave garbage
lying around since the program will end anyways. Thats bullshit of the
highest magnitude.
In compare(), for example, rely on a const reference instead. It will
do away with the bugs.
>
I have some misconception problem or it is a problem specific to g++?
g++ is correct.
I'm not getting into an arguement about what Interface should or should
not have. Lets leave that for another day.
In order to coagulate or join an inheritance tree at a single
interface, one uses virtual inheritance. That will fix the fact that
Comparable does not define getName().
Test the code below by removing the virtual BaseClass d~tor. You'll be
in for a surprise.
As long as the Interface and Comparable have no members, they don't (or
shouldn't?) need a virtual destructor. Can someone please confirm that?
#include <iostream>
#include <ostream>
#include <string>
class Interface
{
public:
~Interface() { std::cout << "~Interface()\n"; }
virtual std::string getName() const = 0;
};
class BaseClass : virtual public Interface
{
std::string name;
public:
BaseClass(std::string s) : name(s) { }
virtual ~BaseClass() { std::cout << "~BaseClass()\n"; }
std::string getName() const { return name; }
};
class Comparable : virtual public Interface
{
public:
~Comparable() { std::cout << "~Comparable()\n"; }
virtual bool compare(const Interface& value) const = 0;
};
class Person : public BaseClass, public Comparable
{
public:
Person(std::string s) : BaseClass(s) { }
~Person() { std::cout << "~Person()\n"; }
bool compare(const Interface& value) const
{
return getName() == value.getName();
}
};
int main()
{
Person person1("Annie");
BaseClass* p2 = new Person("Betty"); // carefull: base pointer
std::cout << "Does person1 have the same name as peson2? ";
std::cout << (person1.compare(*p2) ? "yes" : "no");
std::cout << std::endl;
delete p2; // correctly invokes the Person d~tor
// if and only if ~BaseClass() is virtual
Person person3("Annie");
std::cout << "Does person1 have the same name as peson3? ";
std::cout << (person1.compare(person3) ? "yes" : "no");
std::cout << std::endl;
return 0;
}
/*
Does person1 have the same name as peson2? no
~Person() // delete p2 correctly invokes ~Person()
~Comparable()
~BaseClass()
~Interface() // p2 is actually finally zapped here
Does person1 have the same name as peson3? yes
~Person()
~Comparable()
~BaseClass()
~Interface()
~Person()
~Comparable()
~BaseClass()
~Interface()
*/
It might be useful to note that a d!tor declared as virtual propagates
its virtuality up the ladder. The Person d~tor is therefore virtual as
written above. So it would be perfectly safe to derive from that Person
class and continue to use a BaseClass pointer for allocations /
deallocations.
A better name for BaseClass would probably be Character, Unit, Sapien,
Player or Mammal.
