virtual keyword for the derived class

[jeffc]

And while we're at it, add
another keyword 'pure' so we can get rid of that strange
"pseudo-inizialize with 0 to make it pure virtual" syntax.

Yeah, that's a no-brainer.

 

[Siemel Naran]

Karl Heinz Buchegger wrote:

I'd call them 'virtual' and 'override'. And while we're at it, add
another keyword 'pure' so we can get rid of that strange
"pseudo-inizialize with 0 to make it pure virtual" syntax.

That would be tough to do that as the = 0 is firmly embedded into the
language (and I think for C# too). I also liked a way to make the function
inherited as pure virtual, in order to force derived class authors to define
the function, for which two equal signs seems appropriate, for example Base
* clone() const == 0.

Can you give an example of this? I've never seen it done before, so am
curious.

 

[Richard Herring]

Richard Herring wrote in in
comp.lang.c++:


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.

But it class can't prevent further derivations from manipulating it
virtually, whether that was "intended" or not.

I think this is where we differ: you see the virtual declaration as just
a statement about the base class, whereas I think it's part of the
contract imposed transitively on _all_ subsequently derived classes,
whether they like it or not. 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.

If that were possible then derived wouldn't be a base, so inheritance
would be inappropriate.

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.

The derived class *is a* base, anyone further deriving should expect
it to behave like the base and should read the base clases documentation.

That cuts both ways. Since it *is a* base, it should declare everything
the same way, including virtual functions ;-)

 

[Rob Williscroft]

Richard Herring wrote in in
comp.lang.c++:

But it class can't prevent further derivations from manipulating it
virtually, whether that was "intended" or not.

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.

I think this is where we differ: you see the virtual declaration as
just a statement about the base class,

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.

whereas I think it's part of the
contract imposed transitively on _all_ subsequently derived classes,
whether they like it or not.

They should like it, otherwise why derive (IOW they should "lump" it

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.

They acknowledge that obligation with the " ... : public base ... "
part of the class declaration.

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.

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.

 

[jeffc]

That would be tough to do that as the = 0 is firmly embedded into the
language

Always someone around to rain on the parade.

I also liked a way to make the function
inherited as pure virtual, in order to force derived class authors to define
the function, for which two equal signs seems appropriate, for example Base
* clone() const == 0.

Double yuck. Blech.