By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,835 Members | 1,951 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,835 IT Pros & Developers. It's quick & easy.

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

P: n/a
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

Sep 28 '07 #1
Share this Question
Share on Google+
8 Replies


P: n/a
puzzlecracker wrote:
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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Sep 28 '07 #2

P: n/a
On Sep 28, 6:30 am, puzzlecracker <ironsel2...@gmail.comwrote:
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.

Sep 28 '07 #3

P: n/a
On Sep 28, 6:30 am, puzzlecracker <ironsel2...@gmail.comwrote:
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

Sep 28 '07 #4

P: n/a
On Sep 28, 7:30 am, puzzlecracker <ironsel2...@gmail.comwrote:
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

Sep 28 '07 #5

P: n/a
On Sep 28, 7:30 am, puzzlecracker <ironsel2...@gmail.comwrote:
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

Sep 28 '07 #6

P: n/a

"werasm" <we****@gmail.comwrote in message
news:11*********************@o80g2000hse.googlegro ups.com...
On Sep 28, 7:30 am, puzzlecracker <ironsel2...@gmail.comwrote:
>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
Sep 28 '07 #7

P: n/a
On Sep 29, 1:46 am, "Howard" <m...@here.comwrote:
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

Sep 29 '07 #8

P: n/a
On Sep 29, 10:32 am, werasm <wer...@gmail.comwrote:
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
>
Regards,

Werner

Sep 29 '07 #9

This discussion thread is closed

Replies have been disabled for this discussion.