Prev: A Windows object named "Instance"...
Next: Access violation in oleaut32.dll
From: Lorry Astra on 17 Apr 2008 10:15
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
From: Victor Bazarov on 17 Apr 2008 11:19
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


From: Ulrich Eckhardt on 17 Apr 2008 11:25
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
From: Duane Hebert on 17 Apr 2008 11:54

"Ulrich Eckhardt" <eckhardt(a)satorlaser.com> wrote in message
news:5p6kd5-mr6.ln1(a)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.


From: skidmarks on 17 Apr 2008 13:27
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
 |  Next  |  Last
Pages: 1 2 3
Prev: A Windows object named "Instance"...
Next: Access violation in oleaut32.dll