Re: How many bytes per Italian character?
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:3v0l13t0rnuvfsevfm9m8habbpuoijuos9@4ax.com...
On Mon, 9 Apr 2007 10:39:35 -0700, "David Ching"
<dc@remove-this.dcsoft.com> 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