Polymorphism question - not working like I tought

Ok, since I`m from Java background I tried to do the following
like in the Java, at first. Consider the Java code:

Code:

---

public abstract class Animal
{
  public abstract void makeVoice();  // no implementation
}

public class Dog implements Animal
{
  // the implementation of abstract method
  public void makeVoice()
  {
    System.out.println("WUF!");
  }
}

---

now, I tried to convert the above:

Code:

---

class Animal
{
private:
protected:
public:
  virtual ~Animal() {}
  virtual void makeVoice() = 0; 
};

class Dog : public Animal
{
private:
protected:
public:
  ~Dog() {}
  void makeVoice() { cout<<"WOF!";}
}

---

All fine this far. Ok, I can do thefollowing with Java

Code:

---

Animal animal = new Dog();
animal.makeVoice();  // -> "WOF!"

---

but if I do it with C++

Code:

---

Animal *animal = new Dog(); 
animal->makeVoice();  // this won`t compile

----------
c:/djgpp/lang/cxx-v3/bits/stl_construct.h:78: cannot allocate an object of type
  `Animal'
c:/djgpp/lang/cxx-v3/bits/stl_construct.h:78:  since type `Animal' has
  abstract virtual functions
-----------

---

....but I assigned the animal to of type Dog, which implements
the needed function.
What I`m doing wrong here?

Apart from a missing semicolon at the end of class Dog, I can't see anything wrong with this. Are you sure there are no other pure virtual functions in Animal that Dog doesn't implement?

Like Graham said the only thing, which I see wrong is the semicolon missing. Also you should ALWAYS make your destructors virtual.

yes, they are all implemented ( the animal example was just a similar case to my real implementation )

in my real code, I put "Animal" references to a vector, but the compiler says:

Code:

---

c:/djgpp/lang/cxx-v3/bits/stl_vector.h:579: cannot allocate an object of type 'Animal'
c:/djgpp/lang/cxx-v3/bits/stl_vector.h:579:  since type `Animal' has abstract virtual functions

---

All abstract functions are implemented.
I can compile whitout any errors the 'Animal' and 'Dog' classes and I can use, for example, the 'Dog' class as such. But
when I use it like:

Code:

---

Animal *animal = new Dog();
animal->doStuff(); -> won`t compile ????

---

Quote:

---

Originally posted by usmarine
Also you should ALWAYS make your destructors virtual.

---

Not really a must, virtual destructor is needed only when polymorphic behavior is needed by using the base class pointer. If there isn't a requirement for polymorphic behavior or you don't want people inherit from the class, it is alright not to declare the destructor virtual.

Quote:

---

Originally posted by halmark6Z
I can compile whitout any errors the 'Animal' and 'Dog' classes and I can use, for example, the 'Dog' class as such. But
when I use it like:

Code:

---

Animal *animal = new Dog();
animal->doStuff(); -> won`t compile ????

---

---

If you have a problem compiling the code, it is imperative that you post the exact code you are having a problem with. The reason is that we have to guess what your new "doStuff" is, since we have no idea how it's declared in your classes. This just tends to lead to guesses, and others "filling in" code that may or may not be the cause of the compiling error.

For example, this code compiles and runs correctly, after I corrected the issue of using objects instead of pointers:

Code:

---

#include <iostream>

class Animal
{
    private:
    protected:
    public:
      virtual ~Animal() {}
      virtual void makeVoice() = 0; 
};

class Dog : public Animal
{
    private:
    protected:
    public:
      ~Dog() {}
      void makeVoice() { std::cout<<"WOF!";}
};

int main()
{
    Animal* animal = new Dog();
    animal->makeVoice(); 
    delete animal;
}

---

Now are we to assume that this doesn't compile at your end, or is it something else you have introduced that doesn't compile?

Regards,

Paul McKenzie

you are right, the Aniamal code worked. I`ll format my code
and put it here ... just a moment ...

Just a note: the destructor as posted in the original is virtual - it's declared virtual in Animal, so is implicitly virtual in Dog (that was one of the things that I checked).

Paul: good spot - I completely missed the lack of a "*" on the declaration. I would have though that the compiler would have caught it, though... oh, well, maybe not.

Graham you are wrong!

Just because the destructor is virtual in the abstract class does not mean it is in the inherited class. Try it an see. You will leak memory big time and this is a mistake which people make all of the time. That is why I said the destructor should always be virtual so this problem never occurs.

ISO C++ standard 12.4/7

Quote:

---

A destructor can be declared virtual (10.3) or pure virtual (10.4); if any objects of that class or any derived class are created in the program, the destructor shall be defined. If a class has a base class with a virtual destructor, its destructor (whether user- or implicitly- declared) is virtual.

---

(My emphasis).

It's your compiler that's wrong, I'm afraid

I think Graham is correct.

From the ISO C++ Standard, Section 12.4 Destructors,
paragraph 7 :

Quote:

---

If a class has a base class with a virtual destructor, its
destructor (whether user- or implicitly- declared) is virtual.

---

Sorry, Graham beat me to it.

Code:

---

//////////////////////////////////////////////////////////////////////
#ifndef INCLUDED_CUSTOMER
#define INCLUDED_CUSTOMER

#include <string>
#include <fstream>

using namespace std;


class Customer
{
protected:
        string name;
        string pid;
        double debt;
public:

        virtual ~Customer() {}

virtual void setName(string nam)
{
        name = nam;
}

virtual string getName()
{
        return name;
}

virtual void setPid(string p)
{
        pid = p;
}

virtual string getPid()
{
        return pid;
}

virtual void setDebt(double comp) = 0;

virtual double getDebt() = 0;

virtual void serialize(ofstream& file) = 0;

virtual void deSerialize(ifstream& file) = 0;

};
#endif

---

Code:

---


//////////////////////////////////////////////////////////////////////
#ifndef INCLUDED_REGULARCUSTOMER
#define INCLUDED_REGULARCUSTOMER


#include "customer.hpp"

#include <string>
#include <fstream>
#include <sstream>
#include <iostream>
#include <cstdio>

using namespace std;

class RegularCustomer : public Customer
{
private:
      int visit_times;

public:

RegularCustomer ()
{
    visit_times= 0;
}

~RegularCustomer ()
{

}

void setVisits(int m)
{
        visit_times = m;
}

int getVisits()
{
        return visit_times;
}

virtual double getDebt()
{
        return debt;       
}

void setDebt(double d)
{
        debt = d;
}

// write contents to given text file
void serialize(ofstream& file)
{
  // bunc of lines, never any complaints from here
}

// load contents from file
void deSerialize(ifstream& file)
{
        const int BUF_SIZE = 80;

        try
        {
                char line[BUF_SIZE];
                clearBuffer(line, BUF_SIZE);

                double debt= 0.0;
                int visit_t= 0;

                if(file.is_open())
                {
                        // check for the corrrect start tag
                        file.read(line, 1);
                        if(!line[0] == '@')
                        {
                                return;
                        }

                        // parse name
                        file.getline(line, BUF_SIZE, '#');
                        string name(line, BUF_SIZE);
                        // trim name
                        setName(name);
                        // parse pid
                        file.getline(line, BUF_SIZE, '#');
                        string pid(line, BUF_SIZE);
                        // trim pid
                        setPid(pid);
                        // parse debt
                        file.getline(line, BUF_SIZE, '#');
                        debt= atof(line);
                        setDebt(debt);
                        // parse months
                        file.getline(line, BUF_SIZE, '#');
                        visit_t = atoi(line);
                        setVisits(months);
               
                }
        }
        catch(...)
        {

        }
}

};
#endif

---

[CODE]
#ifndef INCLUDED_PLATINUMCUSTOMER
#define INCLUDED_PLATINUMCUSTOMER

#include "RegularCustomer.hpp"

#include <string>
#include <sstream>
#include <iostream>
#include <cstdio>


using namespace std;

class PlatinumCustomer: public RegularCustomer
{
private:
double bonus;
double bonusLimit;

public:

PlatinumCustomer()
{
bonus = 0;
bonusLimit = 0;
}

~Salesman()
{

}

void setBonus(double bon)
{
bonus = bon;
}

double getBonus()
{
return bonus;
}

void setBonusLimit(double bonl)
{
bonusLimit = bonl;
}

double getBonusLimit()
{
return bonusLimit;
}

double getDebt()
{
return RegularCustomer::getDebt() * 0.95;
}

void serialize(ofstream& file)
{
// all goes fine here
}

void deSerialize(ifstream& file)
{
const int BUF_SIZE = 80;

try
{
char line[BUF_SIZE];
clearBuffer(line, BUF_SIZE);

double debt = 0.0;
double bon = 0.0;
double bonusL = 0.0;
int visits = 0;

if(file.is_open())
{
file.read(line, 1);
if(!line[0] == '@')
{
return;
}

// parse name
file.getline(line, BUF_SIZE, '#');
string name(line, BUF_SIZE);
// trim name
setName(name);
// parse pid
file.getline(line, BUF_SIZE, '#');
string pid(line, BUF_SIZE);
// trim pid
setPid(pid);
// parse debt
file.getline(line, BUF_SIZE, '#');
debt= atof(line);
setDebt(debt);
// parse visits
file.getline(line, BUF_SIZE, '#');
visits= atoi(line);
setVisits(visits);
// parse bonus
file.getline(line, BUF_SIZE, '#');
bon = atof(line);
setBonus(bon);
// parse bonus limit
file.getline(line, BUF_SIZE, '#');
bonusL = atof(line);
setBonusLimit(bonusL);
}
}
catch(...)
{

}
}

};
#endif

[CODE]

in the main program, I have a function:

Code:

---

vector<Employee> loadCustomers(const char* filename)
        {
                // the customers stored here
                vector<Customer> customers;
                ifstream datafile;

                try
                {
                        char line[80];
                        datafile.open(filename);

                        if(datafile.is_open())
                        {
                                do
                                {
                                        datafile.getline(line, 80, '#');
                                        // check for Customer start tag
                                        if(line[0] == '@')
                                        { 
                                                Customer *customer= NULL;
                                                string temp(line,2);
                                       
                                                // returns just an int, see below
                      switch(getObjectType(temp.c_str()))
                                                {
                                                case REGULAR:

                                                        customer= new  RegularCustomer();
                                                        customer->deSerialize(datafile);        // complains about this
                                                        break;
                      .....
                      .....
                    } // switch
 
                  if(customer!= NULL)
                                                        personel.push_back(*customer); // complains about this

---

ps. hopefully I didn`t left any typos but here`s the structure of the program

Which line gives the error??

Well then smart guy what compiler has implemented it successfully. I know for a fact gcc and Microsoft hasn't.

I really don't care what ISO says! If Microsoft or Linux has not implemented it then I certainly cannot rely on it. So like I originally said, "we should always declare destructors as virtual."

If you don't then you are asking for trouble. It's a good programming technique.

Instead of admitting you were wrong when presented proof, you switch to insults. Nice.

Anyway, I'll take a shot in the dark for the OP's problem. He mentioned using a vector.

Code:

---

std::vector<Animal>

---

which won't work for an abstract class and will work incorrectly for any polymorphic class because the data will be sliced.

Instead your data structure should be:

Code:

---

std::vector<Animal*>

---

Actually, I don't know of any compiler that does not
implement it correctly. Following code works according
to the standard on the following compilers :

microsoft VC++ version 5
g++ version 2.95
g++ version 3.22
Intel C++ compiler
Portland Group C++ comiler

Code:

---

include <iostream>

using namespace std;

class B
{
public:

    virtual ~B() { cout << "B\n"; }
};

class D : public B
{
public:

    ~D() { cout << "D\n"; }
};



int main()
{

    B* pd = new D;
    delete pd;

    return 0;
}

---

I am not wrong! And I have seen no proof to prove otherwise! Did I ever mention ISO when stating he should always make destructors virtual.

And actually he started it. I was only pointing out a simple fact that all C++ programmers should know!

Quote:

---

Originally posted by usmarine
I am not wrong! And I have seen no proof to prove otherwise!

---

State what would constitute proof in your mind, and I'm sure we can provide it.

On the otherhand, please provide an example where a derived class does not inherit the 'virtualness' of a destructor.

Stating that you are right, no matter how many explanation points you use, does nothing to support your argument. However, we all tend to be logical people and will be swayed with a persuasive argument.

Jeff

um, if I ask too stupid questions, just ignore. Anyway, I`m grateful for any help!

Quote:

---

Originally posted by halmark6Z
um, if I ask too stupid questions, just ignore. Anyway, I`m grateful for any help!

---

You're not asking stupid questions, and we're happy to help. You said you were using a vector. It must be a vector of pointers if you need it behave polymorphically.

Jeff

sliced?

Quote:

---

which won't work for an abstract class and will work incorrectly for any polymorphic class because the data will be sliced.

---

I`ll fix my vectors to <Animal*>

and I`ll fix my destructors


ps. I started using C++ last tuesday, so I`m not yet a C++ pro
altough I have a rather long Java/Assembly:) background.

I forgot to ask, did you observe any other / general flaws in the Customer - RegularCustomer - PlatinumCustomer classes ( in addition to destructor) ?

Quote:

---

Originally posted by halmark6Z
I forgot to ask, did you observe any other / general flaws in the Customer - RegularCustomer - PlatinumCustomer classes ( in addition to destructor) ?

---

I have to admit, I didn't take the time to look over it. I'm at work right now, and use time during compiles to answer questions as best I can in that time.

Jeff

jfaust

you saved my day!
<Animal*> did the trick :p

thanks for you too usmarine , destructors fixed.

ok, let`s see if I can spell it right:


void doStuff(const vector<Animal*> *animals)


-> a pointer to a vector that holds pointers to Animal objects

my book isn`t too good. It has a section about STL, but the vector
part tells only about how to store integers or strings in it. Nothing about "advanced" usage.

Many thanks again!

Just to add,

Even the first C++ compilers written for the PC (Turbo C++ 1.0, Visual C++ 1.0, etc.) implement the correct behavior for virtual destructors. I'm talking about the late 1980's/early 1990's.

If compilers that are 15 years old implement the correct behavior for virtual destructors, I highly doubt any compiler made recently would botch such a simple rule about virtual destructors. If it did, it would be in the you-know-what list of compilers to never use.

As others have mentioned:

If the base class destructor is virtual, then the virtualness remains for any derived classes. Plain and simple. There is no need to declare all your derived class destructors as virtual (but it doesn't hurt, since it serves as a good comment). Any behavior such as memory leaks occuring is more than likely a programming bug than a buggy compiler.

Regards,

Paul McKenzie

[moderator comments: I split the name-calling off the thread, there really is no need for things like that ]