| Topic: |
DEVELOP > c-Plus-Plus |
| User: |
"puzzlecracker" |
| Date: |
17 Jan 2005 11:12:52 AM |
| Object: |
abstract class |
Can we provide definition for not pure virtual functions (PVF) i.e.
methods in Abstract class - given that we have at least one PVF? IF
yes, where would it be used? can a suggestive example be provided?
thx
.
|
|
| User: "chris" |
|
| Title: Re: abstract class |
17 Jan 2005 11:33:56 AM |
|
|
puzzlecracker wrote:
Can we provide definition for not pure virtual functions (PVF) i.e.
methods in Abstract class - given that we have at least one PVF? IF
yes, where would it be used? can a suggestive example be provided?
I'm not sure what you want (assuming this isn't just a homework
question). You can definatly have non-pure virtual functions in a class
with pure virtual functions. You'd want them whenever you have an
abstract class where there exists some common overloadable functionality
all objects of that type (and derived types) want.
.
|
|
|
| User: "puzzlecracker" |
|
| Title: Re: abstract class |
17 Jan 2005 11:57:03 AM |
|
|
I was interested of whether it is needed, for you cannot create an
object of an abstract class, so having the definition appears to be an
exercise in futility.
Actually, I see one intuitive explanation, that are objects of
subclasses should have identical implementation of a method in the base
class... is it a valid case, are there more cases where it is needed?
thanks.
.
|
|
|
| User: "Mike Wahler" |
|
| Title: Re: abstract class |
17 Jan 2005 12:58:32 PM |
|
|
"puzzlecracker" <ironsel2000@gmail.com> wrote in message
news:1105984623.951988.136420@c13g2000cwb.googlegroups.com...
I was interested of whether it is needed, for you cannot create an
object of an abstract class, so having the definition appears to be an
exercise in futility.
No it's not. It can provide a 'default' behavior for
objects of derived type which don't implement it.
Actually, I see one intuitive explanation, that are objects of
subclasses should have identical implementation of a method in the base
class...
:-)
is it a valid case,
Sure, why not? But of course 'validity' can only be
assessed for each particular heirarchy design.
are there more cases where it is needed?
I don't think so, but I could easily be overlooking something.
I wouldn't worry about it, just use it if it seems appropriate
to your design. Actually it could also be used as a 'place holder'
for code you haven't written yet, letting you have a 'complete'
entity for testing.
-Mike
.
|
|
|
|
| User: "le ténébreux" |
|
| Title: Re: abstract class |
17 Jan 2005 11:54:31 PM |
|
|
"puzzlecracker" <ironsel2000@gmail.com> wrote:
I was interested of whether it is needed, for you cannot create an
object of an abstract class, so having the definition appears to be an
exercise in futility.
Actually, I see one intuitive explanation, that are objects of
subclasses should have identical implementation of a method in the base
class... is it a valid case, are there more cases where it is needed?
thanks.
Even if only a large portion (not all) of your derived classes are
going to use the same implementation, giving that definition in the
base class will save you from having to define it for each of those.
For example, I'm working on a set of Windows GUI wrapper classes.
Each window class uses a completely different method for processing
messages from the OS, so I've declared a pure virtual function in
the base class for that. On the other hand, they almost all, with
a few exceptions, use the same method for repositioning and resizing
when their parent window changes, so I put that implementation into
the base class and just override it in the few cases where it needs
to be different.
.
|
|
|
|
|
|
| User: "Victor Bazarov" |
|
| Title: Re: abstract class |
17 Jan 2005 11:18:59 AM |
|
|
puzzlecracker wrote:
Can we provide definition for not pure virtual functions (PVF) i.e.
methods in Abstract class - given that we have at least one PVF? IF
yes, where would it be used? can a suggestive example be provided?
Yes. Wherever the design needs it to be used. Do it yourself.
.
|
|
|
|
|
Related Articles |
|
|
