Polymorphism question - not working like I tought

[usmarine]

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.

[jfaust]

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.

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:

std::vector<Animal*>

[Philip Nicoletti]

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

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;
}

[usmarine]

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!

[jfaust]

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

[halmark6Z]

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

[jfaust]

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

[halmark6Z]

sliced?

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.

[halmark6Z]

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

[jfaust]

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

[halmark6Z]

jfaust

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

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!

[Paul McKenzie]

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

[Yves M]

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