Re: Testing Program Question
* Leigh Johnston:
Once you accept that abstract interfaces (which contain public pure
virtual
functions) are fine all bets are off and this rule of yours (and Herb's)
falls over.
Ignoring the fallacy of begging the question, it is totally
ignorant to claim that "abstract interface" == "*public* pure
virtual functions". Are you sure you want to make that claim?
Here is an abstract interface
class Foo
{
public :
void func ( ) { implFunc() ; }
protected :
virtual void implFunc ( ) = 0 ;
} ;
Notice there is no *public* pure virtual.
You know, really, do think it is that simple? Do think that
all these experts who have actually *thought* (as opposed to
just *felt*) about this topic forgot abstract bases? Do you
think all it takes if for Leigh to wave "abstract interfaces"
in their face and then all their reasoning just "falls over"?
Really man, get ahold of yourself. Don't be so vociferously
ignorant. At least learn about a topic before publicly
flailing and crying about it.
KHD
What utter garbage, get a clue. There is nothing wrong with public
virtual functions. There are times when it is necessary to change a
public virtual to a private/protected one but that does not rule out the
use public virtual functions.
It's an engineering issue and more like a context-dependent preference than an
absolute rule. C++ is geared towards large code sizes. Since a public virtual
routine can be called directly by client code, and can be overridden my many
subclasses, there's no convenient way to intercept calls to it. A non-virtual
routine provides an interception point, a hook, where pre- and post- conditions
can be checked, say. In a small program you may know about all derived classes
and their usage and it's no problem, that's true.
Essentially those who advocate "no public virtuals" have found that such
checking and whatever else one might put into the non-virtual public routine
saves work -- for others -- for their kind of large scale development.
If C++ had had support for Design By Contract (where you can outfit a virtual
with pre- and post- condition checking, and have that applied automatically for
an override) then one main argument against public virtuals would perhaps be
moot. But the DBC proposal stranded on technicalities, it turned out to be
extremely difficult to define things exactly for C++, in particular that during
a call of a routine the class invariant may be temporarily invalid, and how does
one diffentiate between internal calls and client-code calls? As with modules
and much else, in C++ one has to emulate the functionality of some hypothetical
higher level language by applying conventions systematically, and by avoiding
the troublesome cases that language support would have had to handle.
Cheers & hth.,
- Alf