About pure virtual function

Here I'd like to quote a segment of code from Thinking In C++ (a book writen
by Bruce Eckel) to expain my question.

class Pet
{
public:
virtual void speak() const = 0;
virtual void eat() const = 0;
};

class Dog : public Pet {
public:
void eat() const {}
};

int main()
{
// Dog g;
}

If I define an object of class Dog and compile it, it must be an error, 'cos
I don't define another one in class Dog, but I consider that whether the
compiler should tell me what is wrong when I don't define object "d". Because
I always feel that the current state of class Dog is like a trap, and it
doesn't have any meaning . Am i right?

I think it is like a trap, please see this inheritance.

class Labrador_Retriever : public Dog
{
public:
void eat() {}
};

if I just inherite from base class and I don't define it's object, that
means I can't find my error till the very time. I think that's amazing.

Thank you for your help



Lorry

Victor
Thu Apr 17 10:19:33 CDT 2008

Lorry Astra wrote:
> Here I'd like to quote a segment of code from Thinking In C++ (a book
> writen by Bruce Eckel) to expain my question.
>
> class Pet
> {
> public:
> virtual void speak() const = 0;
> virtual void eat() const = 0;
> };
>
> class Dog : public Pet {
> public:
> void eat() const {}
> };
>
> int main()
> {
> // Dog g;
> }
>
> If I define an object of class Dog and compile it, it must be an
> error, 'cos I don't define another one in class Dog, but I consider
> that whether the compiler should tell me what is wrong when I don't
> define object "d". Because I always feel that the current state of
> class Dog is like a trap, and it doesn't have any meaning . Am i
> right?

"Trap"? No. The life is simpler. The class 'Pet' is *abstract*.
You cannot instantiate it (create a stand-alone object of that
class). The class 'Dog' is also abstract (since it inherits two
pure virtual functions but only "de-purifies" one of them, so it
does *still* have one pure virtual function). Now, *unless* you
try to instantiate 'Dog', the compiler should not tell you anything
because it's not an error to have a pure virtual function in your
class. It's only illegal to instantiate it.

>
> I think it is like a trap, please see this inheritance.
>
> class Labrador_Retriever : public Dog
> {
> public:
> void eat() {}
> };

Huh?

>
> if I just inherite from base class and I don't define it's object,
> that means I can't find my error till the very time. I think that's
> amazing.

Till what very time? "Amazing"? Are you complaining because the
compiler does not explicitly tell you that you have abstract
classes in your program?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Ulrich
Thu Apr 17 10:25:56 CDT 2008

Lorry Astra wrote:
> class Pet
> {
> public:
> virtual void speak() const = 0;
> virtual void eat() const = 0;
> };
>
> class Dog : public Pet {
> public:
> void eat() const {}
> };
>
> int main()
> {
> // Dog g;
> }
>
> If I define an object of class Dog and compile it, it must be an error,
> 'cos I don't define another one in class Dog, but I consider that whether
> the compiler should tell me what is wrong when I don't define object "d".

I guess that you mean that it must be an error because you didn't define
speak(), which is true. I have no idea which object "d" you mean...

> Because I always feel that the current state of class Dog is like a trap,
> and it doesn't have any meaning . Am i right?

Since not all pure virtual functions have been implemented, class Dog also
has pure virtual functions by inheritance, so it can't be instantiated.
This is by itself not wrong, though it can be confusing to the new user.

> I think it is like a trap, please see this inheritance.
>
> class Labrador_Retriever : public Dog
> {
> public:
> void eat() {}
> };
>
> if I just inherite from base class and I don't define it's object, that
> means I can't find my error till the very time. I think that's amazing.

Hmmm, I think if you try to instantiate that class the compiler will tell
you that it can't because speak() isn't implemented. It will also point you
to the place that speak() was declared.

So far, I can't find anything wrong with this behaviour, but I agree that it
is something you have to get used to. In general, C++ is not 'nice'. If you
make a mistake, you will feel it, but that's the price you pay for the
power you wield with this language.

Uli

--
C++ FAQ: http://parashift.com/c++-faq-lite

Sator Laser GmbH
Geschäftsführer: Michael Wöhrmann, Amtsgericht Hamburg HR B62 932

Duane
Thu Apr 17 10:54:17 CDT 2008


"Ulrich Eckhardt" <eckhardt@satorlaser.com> wrote in message
news:5p6kd5-mr6.ln1@satorlaser.homedns.org...
> Lorry Astra wrote:
>> class Pet
>> {
>> public:
>> virtual void speak() const = 0;
>> virtual void eat() const = 0;
>> };
>>
>> class Dog : public Pet {
>> public:
>> void eat() const {}
>> };
>>
>> int main()
>> {
>> // Dog g;
>> }
>>
>> If I define an object of class Dog and compile it, it must be an error,
>> 'cos I don't define another one in class Dog, but I consider that whether
>> the compiler should tell me what is wrong when I don't define object "d".
>
> I guess that you mean that it must be an error because you didn't define
> speak(), which is true. I have no idea which object "d" you mean...

I think he has a typo above and he meant "Dog d".

It seems like the OP expected an error because the
class Dog only implemented one of the two pure virtual functions.
Which isn't the case since Dog at this point is also abstract as
both you and Victor have explained.

skidmarks
Thu Apr 17 12:27:01 CDT 2008

A couple of things:
1: You are using a pure abstract function in the base class. This means:
a: The base class is a pure abstract data type.
b: The base class can not be instantiated, i.e., <base class> Name is
not allowed.
c: All derived classes must have all the pure abstract functions defined
within them as: virtual <name>(<parameters>);.
d: Any missing function in the derived classes will cause an error.

2: Your use of <name>(<parameters>) instead of
virtual <name>(<parameters>)
will lead to some unexpected behavior.

As a side note, I usually define a class:
virtual debug(string str) const = 0;

in my base class. This forces all derived classes to have a debug function.
If nothing else, it make me feel better.

Hope I understand your problems and that this helps.

skidmarks

Ben
Thu Apr 17 12:37:50 CDT 2008

skidmarks wrote:
> A couple of things:
> 1: You are using a pure abstract function in the base class. This
> means: a: The base class is a pure abstract data type.

No. The base class may also have static and non-static data and function
bodies, in addition to pure member functions. Even pure member functions
can be given bodies.

> b: The base class can not be instantiated, i.e., <base class> Name
> is not allowed.

True.

> c: All derived classes must have all the pure abstract functions
> defined within them as: virtual <name>(<parameters>);.

False. Any derived class that doesn't provide a body for each abstract
function will also be abstract.

> d: Any missing function in the derived classes will cause an error.

Only if the derived class is instantiated.

>
> 2: Your use of <name>(<parameters>) instead of
> virtual <name>(<parameters>)
> will lead to some unexpected behavior.

The behavior is exactly the same/ It simply is not as clear to a programmer
reading the code for the derived class.

>
> As a side note, I usually define a class:
> virtual debug(string str) const = 0;
>
> in my base class. This forces all derived classes to have a debug
> function. If nothing else, it make me feel better.

Again, abstract derived classes aren't forced to define the function.

>
> Hope I understand your problems and that this helps.
>
> skidmarks

LorryAstra
Thu Apr 17 18:38:00 CDT 2008

I mean: in my code example, class Dog is no useful until it defines all the
pure virtual functions, I think before I define an object of Dog and press
"F7", the compiler should tell me "..... error" instead of waiting for an
object of Dog created in main.

Could you give me an example on how to use class Dog which doesn't include
all pure virtual functions ?


"Ben Voigt [C++ MVP]" wrote:

> skidmarks wrote:
> > A couple of things:
> > 1: You are using a pure abstract function in the base class. This
> > means: a: The base class is a pure abstract data type.
>
> No. The base class may also have static and non-static data and function
> bodies, in addition to pure member functions. Even pure member functions
> can be given bodies.
>
> > b: The base class can not be instantiated, i.e., <base class> Name
> > is not allowed.
>
> True.
>
> > c: All derived classes must have all the pure abstract functions
> > defined within them as: virtual <name>(<parameters>);.
>
> False. Any derived class that doesn't provide a body for each abstract
> function will also be abstract.
>
> > d: Any missing function in the derived classes will cause an error.
>
> Only if the derived class is instantiated.
>
> >
> > 2: Your use of <name>(<parameters>) instead of
> > virtual <name>(<parameters>)
> > will lead to some unexpected behavior.
>
> The behavior is exactly the same/ It simply is not as clear to a programmer
> reading the code for the derived class.
>
> >
> > As a side note, I usually define a class:
> > virtual debug(string str) const = 0;
> >
> > in my base class. This forces all derived classes to have a debug
> > function. If nothing else, it make me feel better.
>
> Again, abstract derived classes aren't forced to define the function.
>
> >
> > Hope I understand your problems and that this helps.
> >
> > skidmarks
>
>
>

Igor
Thu Apr 17 18:55:41 CDT 2008

Lorry Astra <LorryAstra@discussions.microsoft.com> wrote:
> I mean: in my code example, class Dog is no useful until it defines
> all the pure virtual functions, I think before I define an object of
> Dog and press "F7", the compiler should tell me "..... error" instead
> of waiting for an object of Dog created in main.

Why do you expect some special error for Dog, but not for Pet? There's
really not much difference between the two.

> Could you give me an example on how to use class Dog which doesn't
> include all pure virtual functions ?

You derive another class from it, of course.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

LorryAstra
Thu Apr 17 23:44:00 CDT 2008

Thanks.

I've learned all of the answers, I think maybe I misunderstand the concept
of pure virtual function and abstract class when some classed inheritate
from it. What I understand is: If a new class(common class, not abstract one)
inheritates from an abstract class, it must define all of the pure virtual
functions, if not, then this new class has an error and we can justify this
error not until we define an object of this new class.

And what I can get the view of c++ compiler is : if a new class inheritates
from an abstract class, new class doesn't need to define all of the pure
virtual functions, that's no problem, but you can't define an object of this
new class, if you define one, you are wrong.
Is that right?

adebaene
Fri Apr 18 03:56:39 CDT 2008

On 18 avr, 06:44, Lorry Astra <LorryAs...@discussions.microsoft.com>
wrote:
> Thanks.
>
> I've learned all of the answers, I think maybe I misunderstand the concept=

> of =A0 =A0 pure virtual function and abstract class when some classed inhe=
ritate
> from it. What I understand is: If a new class(common class, not abstract o=
ne)
> inheritates from an abstract class, it must define all of the pure virtual=

> functions, if not, then this new class has an error and we can justify thi=
s
> error not until we define an object of this new class.

I think what troubles is that there is no syntaxic difference between
an abstract and a non-abstract class (this is not the case, for
example, in C#).
An abstract class is just a "normal" class which happens to have one
or more pure virtual functions(s). There is nothing particular to that
class regarding it's definition. The only difference is that you
cannot instanciate an object of that class.

Therefore, there is nothing particular the compiler should said about
an abstract class : only if you try to instanciate this class should
the compiler spit out an error message (and so it does...)

Arnaud

Bo
Fri Apr 18 11:06:26 CDT 2008

Lorry Astra wrote:
> Thanks.
>
> I've learned all of the answers, I think maybe I misunderstand the
> concept of pure virtual function and abstract class when some
> classed inheritate from it. What I understand is: If a new
> class(common class, not abstract one) inheritates from an abstract
> class, it must define all of the pure virtual functions, if not,
> then this new class has an error and we can justify this error not
> until we define an object of this new class.
>
> And what I can get the view of c++ compiler is : if a new class
> inheritates from an abstract class, new class doesn't need to
> define all of the pure virtual functions, that's no problem, but
> you can't define an object of this new class, if you define one,
> you are wrong.
> Is that right?

Yes, the derived class is still an abstract class. You can derive
further from this, perhaps several classes, and defined the remaining
functions there.

Like Arnaud said in another post, C++ just has classes. It is our
choice to use them as interfaces or abstract base classes. Nothing in
the languages stops us from mixing the concepts - it is up to us, the
programmers, to choose how to use it.


Bo Persson

Ben
Mon Apr 21 08:44:26 CDT 2008

Lorry Astra wrote:
> Thanks.
>
> I've learned all of the answers, I think maybe I misunderstand the
> concept of pure virtual function and abstract class when some
> classed inheritate from it. What I understand is: If a new
> class(common class, not abstract one) inheritates from an abstract
> class, it must define all of the pure virtual functions, if not, then

But you derived a new abstract class, not concrete (which you called "common
class"), so none of the rest of your reasoning applies.

> this new class has an error and we can justify this error not until
> we define an object of this new class.
>
> And what I can get the view of c++ compiler is : if a new class
> inheritates from an abstract class, new class doesn't need to define
> all of the pure virtual functions, that's no problem, but you can't
> define an object of this new class, if you define one, you are wrong.
> Is that right?