|
From: Ben Voigt [C++ MVP] on 17 Apr 2008 13:37 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
From: Lorry Astra on 17 Apr 2008 19:38 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 > > >
From: Igor Tandetnik on 17 Apr 2008 19:55 Lorry Astra <LorryAstra(a)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
From: Lorry Astra on 18 Apr 2008 00:44 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?
From: adebaene on 18 Apr 2008 04:56 On 18 avr, 06:44, Lorry Astra <LorryAs...(a)discussions.microsoft.com> 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. 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
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: A Windows object named "Instance"... Next: Access violation in oleaut32.dll |