mandatory/optionally overridable virtual functions

[Dilip]

In a polymorphic hierarchy is it common practice to have public
virtual functions in the base class with a default empty
implementation and let the derived classes decide whether they want to
override it or not? In such cases what would be the access levels of
those functions in both base and derived classes?

struct AbstractBase
{
virtual void mandatory_func() = 0;
virtual void optional_func() { }
};

struct concretebase1 : public AbstractBase
{
virtual void mandatory_func() { }
};

struct concretebase2 : public AbstractBase
{
virtual void mandatory_func() { }
virtual void optional_func() { // do something cool }
};

on the face of it, it does seem natural but somehow I can't get it out
of my mind that I just keep adding virtual functions to AbstractBase
for every *specific* action I want to perform from one of the derived
classes. If I have a lot of such operations I am concerned there
would be a virutal function bloat in AbstractBase.

Are my fears misplaced?

 

[Victor Bazarov]

In a polymorphic hierarchy is it common practice to have public
virtual functions in the base class with a default empty
implementation and let the derived classes decide whether they want to
override it or not?

It's one of three common practices. The other two are to leave the
function pure and to actually implement proper behaviour for the base
class object. Come to think of it, that's pretty much all the choices
one has WRT virtual functions in the base class. You can also have
an implementation of a pure function, but I'd guess that it's less
common (except for destructors, maybe).

In such cases what would be the access levels of
those functions in both base and derived classes?

There is no common rule about it. Do as your model domain requires.

struct AbstractBase
{
virtual void mandatory_func() = 0;
virtual void optional_func() { }
};

struct concretebase1 : public AbstractBase
{
virtual void mandatory_func() { }
};

struct concretebase2 : public AbstractBase
{
virtual void mandatory_func() { }
virtual void optional_func() { // do something cool }
};

on the face of it, it does seem natural but somehow I can't get it out
of my mind that I just keep adding virtual functions to AbstractBase
for every *specific* action I want to perform from one of the derived
classes.

Well, *that* doesn't seem sensible. Your motivation here is either
wrong or unclear.

If I have a lot of such operations I am concerned there
would be a virutal function bloat in AbstractBase.

What's a virtual function bloat? Why are you concerned with it?

Are my fears misplaced?

Fears of what? The bloat? Misplaced.

V

 

[Dilip]

Well, *that* doesn't seem sensible. Your motivation here is either
wrong or unclear.

Can I flesh this out a little bit? Lets say I have a client code that
does something like this:

void DoMe(AbstractBase* b1)
{
b1->mandory_func(); // everything is fine and dandy
b1->optional_func(); // no op for whichever classes don't need to
do this
}

If DoMe can be called with any of the concrete dervied classes as
parameter and only one of them needs to implement a particular
operation while the others no-op it out, how would I do it?

What's a virtual function bloat? Why are you concerned with it?

I meant metaphorically -- like seeing a lot of unrelated virtual
functions scattered all over AbstractBase with no relation to each
other (making sense only to derived classes that choose to implement
them).

another quick question: in hierarchies like this do you make the dtor
of AbstractBase ordinary or pure virtual (with an empty impl)?

 

[Victor Bazarov]

Can I flesh this out a little bit? Lets say I have a client code that
does something like this:

void DoMe(AbstractBase* b1)
{
b1->mandory_func(); // everything is fine and dandy
b1->optional_func(); // no op for whichever classes don't need to
do this
}

If DoMe can be called with any of the concrete dervied classes as
parameter and only one of them needs to implement a particular
operation while the others no-op it out, how would I do it?

Well, when you put it like this, yes, that's the only way to do it.
However, why in your model your 'DoMe' function asks the AbstractBase
to perform an operation that only some derived classes should do?
This design doesn't seem sound. It would rather have sense to make
'DoMe' a virtual function of your base and let derived classes decide
whether they want to add to it or substitute it.

void AbstractBase:oMe()
{
this->mandatory_func();
}
...

void SomeDerivedClass:oMe()
{
this->AbstractBase:oMe(); // do what the base is supposed to
this->someAdditionalStuff(); // and more...
}

I meant metaphorically -- like seeing a lot of unrelated virtual
functions scattered all over AbstractBase with no relation to each
other (making sense only to derived classes that choose to implement
them).

Ah. Then, yes, absolutely. You should not do that.

another quick question: in hierarchies like this do you make the dtor
of AbstractBase ordinary or pure virtual (with an empty impl)?

Depends on how you expect to destroy those objects. Since the class
already has some virtual functions, it won't cost more to make the
d-tor virtual as well, so I say, sure, make it virtual. No need to
make it pure, however, unless you want to make sure it's abstract and
you are expecting the purity of other virtual functions to be removed
due to whatever reason.

V

 

[Maarten Kronenburg]

"Dilip" wrote

In a polymorphic hierarchy is it common practice to have public
virtual functions in the base class with a default empty
implementation and let the derived classes decide whether they want to
override it or not? In such cases what would be the access levels of
those functions in both base and derived classes?

struct AbstractBase
{
virtual void mandatory_func() = 0;
virtual void optional_func() { }
};

struct concretebase1 : public AbstractBase
{
virtual void mandatory_func() { }
};

struct concretebase2 : public AbstractBase
{
virtual void mandatory_func() { }
virtual void optional_func() { // do something cool }
};

on the face of it, it does seem natural but somehow I can't get it out
of my mind that I just keep adding virtual functions to AbstractBase
for every *specific* action I want to perform from one of the derived
classes. If I have a lot of such operations I am concerned there
would be a virutal function bloat in AbstractBase.

Are my fears misplaced?

Helper functions for a derived class need not necessarily be in the base
class.
And functions that are identical for all derived classes need not be
virtual.
Think of the pure virtual functions as functions of a driver of hardware:
every operation that the "thing" can do must have a separate pure virtual
function.
Did you also check out:
http://www.parashift.com/c++-faq-lite/virtual-functions.html
and the NonVirtual Interface (NVI) design pattern in the book
C++ Coding Standards by Sutter and Alexandrescu?
Regards, Maarten.

 

[jeffc226]

In a polymorphic hierarchy is it common practice to have public
virtual functions in the base class with a default empty
implementation and let the derived classes decide whether they want to
override it or not?

Sure, I mean if you want to act on the objects polymorphically and a
base class really has nothing to do, then it makes sense. One thing
that I rarely see (in fact most programmers believe it's not even
possible) is to give a default (non-empty) implementation to pure
virtual functions. It makes perfect sense to me, so I'm not sure why
this doesn't get used much.