The private-inheritance variant allows Car to override Engine's virtual functions

[puzzlecracker]

The statement is taken from FAQ [24.2]. What about non-virtual
functions? Can they be overriden? I still don't see a good
justification to prefer private inheritance over composition. In
fact, I have never seen it in a commercial code. If someone did,
please share the use-case and decisions behind it.


Thanks

 

[Victor Bazarov]

The statement is taken from FAQ [24.2]. What about non-virtual
functions? Can they be overriden?

No. The term "override" relates only to virtual functions. Non-
virtual functions are either inherited or hidden. They can also
be overloaded if brought into the derived class' scope with the
help of a 'using' declaration.

I still don't see a good
justification to prefer private inheritance over composition. In
fact, I have never seen it in a commercial code. If someone did,
please share the use-case and decisions behind it.

I am too lazy to search through our multimillion-LOC codebase,
and there is no guarantee I'd find anything. If you don't see
a good justification now, you won't see any justification given
to you as good, either. Goodness is in the eye of the beholder.

V

 

[Jonathan Lane]

The statement is taken from FAQ [24.2]. What about non-virtual
functions? Can they be overriden? I still don't see a good
justification to prefer private inheritance over composition. In
fact, I have never seen it in a commercial code. If someone did,
please share the use-case and decisions behind it.

Thanks

I think it's fair to say that there's nothing that can be done with
private inheritance that can't be done with aggregation/composition.
The usual justification is that you want to aggregate a class and
override some virtual methods that it provides. Consider a class that
will use a timer. The timer has a virtual method OnTick which is
called every n seconds as defined in the class.
You could derive a class and override the OnTick method to do
something specific for your class and then aggregate that derivation.
Or, you could inherit privately and override OnTick within your class
giving you slightly/arguably cleaner code.

 

[tragomaskhalos]

The statement is taken from FAQ [24.2]. What about non-virtual
functions? Can they be overriden? I still don't see a good
justification to prefer private inheritance over composition. In
fact, I have never seen it in a commercial code. If someone did,
please share the use-case and decisions behind it.

Thanks

AFAIK one reason to prefer private inheritance over
composition is to simplify delegation: eg:

class Embedee {
public:
void foo();
int bar(double);
char* baz(int);
void dont_want_to_expose_this_one();
};
class Agreggator : private Embedee {
public:
using Embedee::foo;
using Embedee::bar;
using Embedee::baz;
:
};

This saves having to write and maintain
forwarding functions for these methods.
Of course you can't have more than one
Embedee in this case.
I think one of Herb sutter's "Exceptional
C++" books covers this btw.

HTH

 

[werasm]

The statement is taken from FAQ [24.2]. What about non-virtual
functions? Can they be overriden? I still don't see a good
justification to prefer private inheritance over composition. In
fact, I have never seen it in a commercial code. If someone did,
please share the use-case and decisions behind it.

Thanks

Private inheritance provides a way to give selective polymorphism
e.g. if a class only wants expose his interface to specific
clients, not necessarily because no true isA relationship exists,
but because selective clients may call the methods e.g.

I provide serviceA, ..B, and ..C. I don't want clientB to make
use of serviceA, but I nevertheless want to provide it to whom
I dictate (I've seen an article on this but can't remember where).

One could achieve the same by other means, but private inheritance
makes it easier. We have an example where we have two parallel
hierarchies (3 deep in this case, each level abstracting a
certain responsibility). The bases in the hierarchy make use of
template method pattern to dictate behavior in terms of
derived classes, and they in turn have enough information to
extend the template method (so to speak). Each of the
classes in the hierarchy make use of services provided by
the same class at different levels, and private inheritance
makes this possible. I have contemplated other ways to do
this, but decided that it is more natural to implement using
private inheritance. Of course, template method itself could
have been implemented using a <bridge>, if you know what I
mean? In the above mentioned case though, things played
out nicely using private inheritance and intent was very clear
(IMHO).

Regards,

Werner

 

[werasm]

The statement is taken from FAQ [24.2]. What about non-virtual
functions? Can they be overriden? I still don't see a good
justification to prefer private inheritance over composition. In
fact, I have never seen it in a commercial code. If someone did,
please share the use-case and decisions behind it.

Thanks

Private inheritance provides a way to give selective polymorphism
e.g. if a class only wants expose his interface to specific
clients, not necessarily because no true isA relationship exists,
but because selective clients may call the methods e.g.

I provide serviceA, ..B, and ..C. I don't want clientB to make
use of serviceA, but I nevertheless want to provide it to whom
I dictate (I've seen an article on this but can't remember where).

One could achieve the same by other means, but private inheritance
makes it easier. We have an example where we have two parallel
hierarchies (3 deep in this case, each level abstracting a
certain responsibility).

The bases in one hierarchy make use of
template method pattern to dictate behavior in terms of
derived classes, and they in turn have enough information to
extend the template method (so to speak).

Each of the levels in one hierarchy make use of services provided by
corresponding levels in another hierarchy, and private inheritance
makes this possible. I have contemplated other ways to do
this, but decided that it is more natural to implement using
private inheritance. Of course, template method itself could
have been implemented using a <bridge>, if you know what I
mean? In the above mentioned case though, things played
out nicely using private inheritance and intent was very clear
(IMHO).

Regards,

Werner

 

[Howard]

The statement is taken from FAQ [24.2]. What about non-virtual
functions? Can they be overriden? I still don't see a good
justification to prefer private inheritance over composition. In
fact, I have never seen it in a commercial code. If someone did,
please share the use-case and decisions behind it.

Thanks

Private inheritance provides a way to give selective polymorphism
e.g. if a class only wants expose his interface to specific
clients, not necessarily because no true isA relationship exists,
but because selective clients may call the methods e.g.

I provide serviceA, ..B, and ..C. I don't want clientB to make
use of serviceA, but I nevertheless want to provide it to whom
I dictate (I've seen an article on this but can't remember where).

One could achieve the same by other means, but private inheritance
makes it easier. We have an example where we have two parallel
hierarchies (3 deep in this case, each level abstracting a
certain responsibility). The bases in the hierarchy make use of
template method pattern to dictate behavior in terms of
derived classes, and they in turn have enough information to
extend the template method (so to speak). Each of the
classes in the hierarchy make use of services provided by
the same class at different levels, and private inheritance
makes this possible. I have contemplated other ways to do
this, but decided that it is more natural to implement using
private inheritance. Of course, template method itself could
have been implemented using a <bridge>, if you know what I
mean? In the above mentioned case though, things played
out nicely using private inheritance and intent was very clear
(IMHO).

I find the comments above very confusing. (Does anyone else?)

How does private inheritance allow a class to expose its interface only to
specific clients? What does "the same class at different levels" mean?
What's a "<bridge>"?

Perhaps some code example might illustrate your point(s) better. I'm just
not following.

-Howard

 

[werasm]

I find the comments above very confusing. (Does anyone else?)

How does private inheritance allow a class to expose its interface only to
specific clients?

See the example. Cmd exposes the function execute only to Processor.

What does "the same class at different levels" mean?
What's a "<bridge>"?

Refer to bridge pattern in wikipedia.

Perhaps some code example might illustrate your point(s) better. I'm just
not following.

Here goes:

struct Executable
{
virtual void execute() = 0;
protected:
virtual ~Executable(){ }
};

struct Processor
{
virtual void process( Executable& );
//...
};

class Cmd : Executable
{
public:
Cmd( Processor* p = 0 ): p_( p ){ }
void operator()()
{
if( p_ )
{
p_->process( *this );
}
else
{
execute();
}
}
private:
virtual void execute()
{
//...Some default behavior...
// Most probably overridden
}
Processor* p_;
};


void clientFunction()
{
Processor p;
Cmd cmd( &p );
cmd(); // Processor calls execute...
cmd.execute();//Fails to compile...
}

Regards,

Werner

 

[werasm]

Here goes:

struct Executable
{
virtual void execute() = 0;
protected:
virtual ~Executable(){ }

};

struct Processor
{
virtual void process( Executable& );
//...

};

class Cmd : Executable
{
public:
Cmd( Processor* p = 0 ): p_( p ){ }
void operator()()
{
if( p_ )
{
p_->process( *this );
}
else
{
execute();
}
}
private:
virtual void execute()
{
//...Some default behavior...
// Most probably overridden
}
Processor* p_;

};

void clientFunction()
{
Processor p;
Cmd cmd( &p );
cmd(); // Processor calls execute...
cmd.execute();//Fails to compile...
}

The purpose of this BTW, is to allow the command to be executed
in the context (or thread) or processor when associate with it, and
in the context of its own thread if not. It also allows you to
bind (to derived classes of commands) arguments that get sent
to a callback associated with classes derived from commands.

Unfortunately I can't go the whole nine yards with explaining
this, because the more I explain, the more questions would
be asked, but the little example illustrates the point, I
think.

Regards,

Werner