«

"JKop" <> wrote in message
news:bJlsc.254$...
>
> Here's what I'm getting at:
>
>
> Why would you cast a Dog* to a Mammal*? as in:
>
>
> Mammal restt = new Dog;
> delete restt;

Suppose you've got a list of mammals, and you want them all to (say) jump up
and down and shout "Wahey!" (Clearly all mammals do this on a regular
basis...) You don't want to store separate lists of cats and dogs, you just
want to store mammals. (For a more sensible example, consider storing a list
of controls, - you don't care whether it's a drop-down box, a button, or
whatever, all you're interested in is the fact that when you click on it it
does something.) Consider the following (rather odd ) bit of code:

#include <iostream>
#include <list>

class Mammal
{
public:
virtual void JumpUpAndDownAndShoutWahey() = 0;

virtual ~Mammal()
{
std::cout << "Bye!\n";
}
};

class Dog : public Mammal
{
public:
virtual void JumpUpAndDownAndShoutWahey()
{
std::cout << "I am a dog and I say 'Wahey!'\n";
}

virtual ~Dog()
{
std::cout << "Woof!\n";
}
};

class Cat : public Mammal
{
public:
virtual void JumpUpAndDownAndShoutWahey()
{
std::cout << "I am a cat and I also say 'Wahey!'\n";
}

virtual ~Cat()
{
std::cout << "Miaow!\n";
}
};

int main()
{
std::list<Mammal*> mammalList;
mammalList.push_back(new Dog);
mammalList.push_back(new Cat);
for(std::list<Mammal*>::iterator it=mammalList.begin(),
iend=mammalList.end(); it!=iend; ++it)
{
(*it)->JumpUpAndDownAndShoutWahey();
delete *it; // deleting an instance of a derived class through a
base class pointer - virtual destructor required in the base class or
behaviour is undefined
}
mammalList.clear();
return 0;
}

> as opposed to:
>
>
> Dog restt = new Dog;
> delete restt;
>
>
>
> Anyway, I see what yous are getting at, end of discussion.
>
>
> For the next version of C++ I suggest:
>
> class Mammal
> {
> virtual_ifderived ~Mammal(void);
> };
>
>
>
> -JKop

JKop wrote:
>
> Here's what I'm getting at:
>
> Why would you cast a Dog* to a Mammal*? as in:
>
> Mammal restt = new Dog;
> delete restt;
>
> as opposed to:
>
> Dog restt = new Dog;
> delete restt;

Because the rest of the program (what you didn't show) might look like this:
(untested code, just to show the idea)

class Mammal
{
public:
virtual ~Mammal() {}
virtual std::string MakeNoise() { return "Error: No noise possible"; }
};

class Dog : public Mammal
{
public:
virtual std::string MakeNoise() { return "Wuff, Wuff"; }
};

class Cat : public Mammal
{
public:
virtual std::string MaekNoise() { return "Miau, Miau"; }
};

int main()
{
Mammal* pMammal = NULL;
int type;

cout << "Which mammal should I create (1 = Dog, 2 = cat) ";
cin >> type;

if( type == 1 )
pMammal = new Dog;
else if( type == 2 )
pMammal = new Cat;

if( pMammal )
cout << "The selected mammal makes " << pMammal->MakeNoise();

delete pMammal;
}

--
Karl Heinz Buchegger

JKop wrote:

> For the next version of C++ I suggest:
>
> class Mammal
> {
> virtual_ifderived ~Mammal(void);
> };

What would that do? How would it differ from

virtual ~Mammal ( );

?

"Jeff Schwab" <> wrote in message
news:UaCdnXd6UYUl4jLdRVn-...
> Ele wrote:
> > Is it correct to say that Whenever a class has a virtual member
function,
> > define its destructor as "virtual"?
>
> That's a good rule of thumb.
>
> > Can a destructor as "pure virtual"?
>
> Yes, but I can't think of a case when it's a good idea.

Sometimes people use it as a "trick" to get around the awkward definition of
an abstract class in C++. What if you want an abstract class, but there
isn't any particular function that needs to be pure virtual? Make the
destructor pure virtual.

"Jeff Schwab" <> wrote in message
news:jZ6dnXkrOphjVy3dRVn-...
> David Harmon wrote:
> > On Sat, 22 May 2004 12:29:57 -0400 in comp.lang.c++, Jeff Schwab
> > <> wrote,
> >
> >>>Can a destructor as "pure virtual"?
> >>
> >>Yes, but I can't think of a case when it's a good idea.
> >
> >
> > A pure virtual destructor is sometimes used to make an abstract class,
> > when there are no other virtual functions in that base class than make
> > sense to be pure. You also still provide the destructor implementation
> > in that case.
>
> If you provide an implementation for the destructor, in what way is the
> destructor "pure virtual?"

There is nothing wrong with providing an implementation for a pure virtual
function. The subclass version can simply call the base class version.

"Jeff Schwab" <> wrote in message
news:m-WdnY3J5t0zbS3dRVn-...
> Denis Remezov wrote:
>
> > 10.3.8 says:
> > "A virtual function [...] shall be defined, or declared pure [...] or
both;
> > [...]"
> >
> > So yes, you can provide a definition for a pure virtual function.
>
> Thanks, Denis. I've never seen a pure virtual function with a
> definition before now. Live and learn!

I think it makes perfect sense, but many people have never considered it.
It is the designer's way of saying "you must think about what you want to do
with this function. You can use my implementation as part or all of your
implementation though, if you wish."

"JKop" <> wrote in message
news:9HNrc.124$...
>
> So... when a dog dies, it barks, and then exhales.

How sad.

> Long story short, I don't see why there's a need to give Mammal or Dog
a
> virtual destructor. Could someone please enlighten me?

You just showed why - so when a dog dies, it will also exhale. This is
basic polymorphism - when you have an object such as
Mammal* myDog = new Dog;

"JKop" <> wrote in message
news:MZ2sc.169$...
>
>
> Thanks Stephen Waits and Duane Hebert for your replies, although I found
the
> both of them to be HEAVILY contrived.
>
> Why would one function delete memory allocated by another?
>
> And why would you do the following:
>
> Mammal restt = new Dog;
>
> delete restt;
>
> Looks like child's play to me.

That should be Mammal*. Again, this is basic polymorphism, so you should
read up on that. It's very common in OO code - not at all contrived.

jeffc posted:

> Sometimes people use it as a "trick" to get around the awkward
> definition of an abstract class in C++. What if you want an abstract
> class, but there isn't any particular function that needs to be pure
> virtual? Make the destructor pure virtual.


If there's no particular function that needs to be pure virtual...


Isn't that what an abstract class is all about! ie. There's things it can't
do because "what it is" isn't specific enough. For example, ask a vehicle to
accelerate - Does it step on the gas pedal, does it pull back the throttle,
or does it pedal?


Could you please give me a quick example of where you want a class to be
abstract... YET... there's no particular function that needs to be pure
virtual. An uncontrived example please.


This interests me!


-JKop

Jeff Schwab posted:

> JKop wrote:
>
>> For the next version of C++ I suggest:
>>
>> class Mammal
>> {
>> virtual_ifderived ~Mammal(void); };
>
> What would that do? How would it differ from
>
> virtual ~Mammal ( );
>
> ?
>

The function would *not* be virtual... UNLESS... elsewhere in the program
you have something like:


class Dog : public Mammal


At which point the the compiler makes it virtual. That way there's no
overhead if the class *isn't* derived from... YET... if it is, you have the
functionality of a virtual destructor.

I meant it more as conversation than anything else, ie. I haven't pondered
over the possible pitt-falls.


-JKop