Re: How many bytes per Italian character?

"Doug Harrison [MVP]" <dsh@xxxxxxxx> wrote in message
news:3v0l13t0rnuvfsevfm9m8habbpuoijuos9@xxxxxxxxxx
On Mon, 9 Apr 2007 10:39:35 -0700, "David Ching"
<dc@xxxxxxxxxxxxxxxxxxxxxx> wrote:

OK, now I see where you're headed with this. The derived class needs to
override the InitState() function so it needs to be pure virtual. And it
needs to call the base class's InitState() function somewhere, either in
its
implementation of InitState() or somewhere else, that's why it must not be
private. (But pure virtual functions do not force the derived
implementation to call the base's implementation, I don't think.)

Neither do normal virtual functions, but many require that overrides in
derived classes call up to them anyway; an example is OnInitDialog. It's a
documentation issue, like I said.

So the real problem is that C++ jams two conflicting functionalities into
pure virtual functions. 1) Forcing derived classes to implement it; 2)
Providing a convenient place to implement base functionality for access by
both the base class and derived class.

These are somewhat contrary goals. The common sense usage of pure virtual
functions is to make it pure if the base class has no idea how to
implement
the functionality, and that must be provided by the derived classes. If
the
base class does have some idea of it, and therefore needs to implement the
virtual function, then don't make it pure.

If the derived classes are developed hand in hand with the base as a
unified solution to a problem, and you know the base can't implement the
virtual function completely, there's no conflict.

The derived classes have the
opportunity to supplement/replace the functionality by overriding the
virtual function or not, and if they do override, whether or not to call
the
base class.

The purpose of the derived class in my example is to add its own stuff to
what the base class does. There's no choice here.

It's presumptuous of the base class to assume the derived
classes will be implemented in such a way that they are forced to override
in this case.

Not at all. FWIW, I did characterize defining pure virtual functions in
the
terms, "Offhand, the only time I can recall doing this..." IOW, it isn't
common IME, but I did appreciate the ability to express what I needed to
do
in a short, clear way. To the extent it addressed what I was talking
about,
the alternative you presented requires a parallel set of non-virtual
functions to be defined in order to keep your idea of "pure", well,
"pure".
It doesn't ease the documentation requirement, so it doesn't really gain
anything I consider valuable. It's just a harder way to do it.


I withdraw the non-virtual functions. The only reason I put them there was
because I thought your point was about what the base ctor would call, which
I find out later was not your point at all.

If you still have to document that derived classes need to call the base
pure virtual function, you really don't gain anything by having it pure
then. In fact, your documentation becomes pained having to explain that a)
even though the function is declared pure virtual, there is indeed a body
(which may or may not be visible in the header file), and b) the derived
class must be sure to call it from within the overridden function.

If it were not pure, but simply virtual, you do not have to explain a).


(To put this in C# terms, I defined an interface, had the base class
implement it, and then had the derived classes reimplement it but still
call the base class as part of their implementation.)


This doesn't really apply. The derived class would be derived from the base
class and not the interface then.

-- David


.

Relevant Pages

  • Re: How many bytes per Italian character?
    ... override the InitState() function so it needs to be pure virtual. ... derived classes call up to them anyway; ... both the base class and derived class. ...
    (microsoft.public.vc.mfc)
  • Re: Why cant static methods be overridden?
    ... static void something ... but if it were possible to override ... something in derived classes you can bet people would then want to be able ... to call derived static methods through base class references, ...
    (comp.lang.java.programmer)
  • Re: Can my class tell if one of its virtual members is overloaded?
    ... > that a base class cannot discover anything about derived ... The point is that you can never know what all the derived classes of a ... isn't another type around which *does* override a member. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Not pure virtual functions and mixing virtual and non virtual methods
    ... Should I call base class implementation or not? ... But doing the above assumes that one answer is good for all, that all derived classes will want the base class method called in the same way. ... More generally, the way I see it, if you combine invariant implementation with variant parts, you have no elegant way to change the variant part. ... Following them will remove all inheritance relationships. ...
    (comp.object)
  • Re: What can I store in LPARAM
    ... I'm not saying you're wrong, but with my call back up to the base class, ... may choose to override it completely, or by adding code before or after ... comments below regarding leaf. ... This means that a subclass can't change the method body behind ...
    (microsoft.public.vc.mfc)