Richard Herring wrote in news:Jt16XxFywj$AFwwT@baesystems.com in
comp.lang.c++:
[color=blue][color=green][color=darkred]
>>> Ah, well, IMO virtualness of a member function can't be dismissed as
>>> an implementation detail. It's a major declaration of intent about
>>> what the designer of the base class expects to happen when that
>>> function gets called - possibly by code within the base class itself.[/color]
>>
>>Yes, but that is a quality of the base class, a derived type shouldn't
>>(need to) repeat that statement of intent, unless it has a real need,
>>i.e. it intends to manipulate it virtually itself.[/color]
>
> But it class can't prevent further derivations from manipulating it
> virtually, whether that was "intended" or not.[/color]
Yes, but infact the further derivation's are manipulating/overriding the
"base" sub-object not the currently being declared class. The member is
virtual because (and only because) its virtual in the base class.
The presence of virtual in the derived class implies that new features
it provides are dependant on the possibly overriden implementation of
the virtual member.
IOW, a virtual member offers either or both of:
- That *this* class will use an overriden version.
- That *this* class provides it as an "interface" and others can/will
call the overriden version.
If neither of the above are true then I see the unnesassery virtual
specification as missleading and (at best) redundant.
[color=blue]
>
> I think this is where we differ: you see the virtual declaration as
> just a statement about the base class,[/color]
It is code with a (potential) effect, but it isn't used as code
it is used as documentation, its documentation about the base class
that appears in the derived class.
class derived : public base
{
virtual bool is_open();
public:
bool open( /* whatever */ );
};
Seeing the above I would expect that, is_open() is used polymorphicly
by open() (and/or other members if the example has any).
Other's suggest that it could mean the above or "this is an override
of base's behaviour", if this other meaning is required a comment
does the job.
[color=blue]
> whereas I think it's part of the
> contract imposed transitively on _all_ subsequently derived classes,
> whether they like it or not.[/color]
They should like it, otherwise why derive (IOW they should "lump" it :)
[color=blue]
> From that POV when they repeat the
> redundant "virtual" they are acknowledging that obligation: derived
> "is-a" base, and should therefore state which functions are virtual.[/color]
They acknowledge that obligation with the " ... : public base ... "
part of the class declaration.
[color=blue]
>[color=green][color=darkred]
>>>>OTOH if you expect your class to be derived from and want to allow
>>>>those derived classes to overide you implementation you should make
>>>>the member virtual, but that is independant of wether you've derived
>>>>from a base and are overriding yourself.
>>>
>>> I think I see what you're suggesting, but it doesn't work.
>>> Conceptually it would be as though the first derived class marked the
>>> override as "final" and then offered itself as a new "base" with a new
>>> virtual function that just happens to have the same name. The trouble
>>> is that once you've uncorked virtualness it can't be put back in the
>>> bottle. Base code calling the virtual function will get the most
>>> derived version, not the "final" one of the intermediate class.[/color]
>>
>>If that were possible then derived wouldn't be a base, so inheritance
>>would be inappropriate.[/color]
>
> It would be a new base for derivation, in which the fact that it was
> actually derived from something else was a concealed implementation
> detail.[/color]
Yes, such a feature would break the "is a base" contract, but we can't
do it so there isn't much point in debating it.
Rob.
--
http://www.victim-prime.dsl.pipex.com/ 
