Private Inheritance and Publice Inheritance

[karthikbalaguru]

Hi,
Could someone here tell me some links/pdfs/tutorials to know about the
difference between Private Inheritance and Public Inheritance ?
I am unable to get info w.r.t it.

Thx in advans,
Karthik Balaguru

 

[Daniel T.]

Could someone here tell me some links/pdfs/tutorials to know about the
difference between Private Inheritance and Public Inheritance ?
I am unable to get info w.r.t it.

http://www.parashift.com/c++-faq-lite/private-inheritance.html

 

[Victor Bazarov]

Could someone here tell me some links/pdfs/tutorials to know about the
difference between Private Inheritance and Public Inheritance ?
I am unable to get info w.r.t it.

What book on C++ are you reading that doesn't explain the difference
and the use of access specifiers when deriving?

V

 

[SasQ]

Could someone here tell me some links/pdfs/tutorials
to know about the difference between Private Inheritance
and Public Inheritance?

Inheritance always means "IS A" relationship.
E.g. "Porshe IS A Car".
It means that Porshe could do all the things that
all Cars can do.

Apply public inheritance when you want to describe
"IS A" relationshit to "whole world" By writing
class Porshe : public Car
you say to everyone: "Porshe IS A Car".
Thanks to public inheritance, which defines that
kind of relationship, it's possible to use derived
class [i.e. the Porshe] in every place where the
Car is accepted, because every Porshe is also a Car

Private inherintance could restrict the knowledge
about that family bonds only to the derived class.
The rest of the world will know nothing about that
relationship. The only thing which will be know that,
will be the class's implementation, and only it
will be able to use from that fact.

Some people also asks what is the difference between
private inheritance and composition. Some of them
sees no difference at all, because they focus only
on the fact that in both cases only the class's
implementation can use the contained/base class.
But there is one, very important difference:
overriding virtual methods. You cannot ovverride
a method of contained class, but you can do it
with methods of the [even privately] interface
derived from a base class.

 

[karthikbalaguru]

http://www.parashift.com/c++-faq-lite/private-inheritance.html

Thx for info.

Karthik Balaguru

 

[SasQ]

http://www.parashift.com/c++-faq-lite/private-inheritance.html

"(...)
The 'Car has-a Engine' relationship can also be expressed
using private inheritance:

class Car : private Engine
(...)"

WHAT?!
What sense makes the above?
The "has-a" relationshit is evidently a composition.
If someone think different, let he try to think if
the Car could have more than one engine. I haven't seen
that kind of car, but if we do the same with the plane,
we'll see that it could have more engines than one.
How one could express that with use of [private] inheritance??
It's impossible, ant that's the reason why it should be
done with use of composition.

There is other thing wrong in that example.
It assumes that for the Car class's implementation
the Engine is an ancestor. So, from the perspective
of the implementation, Car is-a Engine [WTF?? LOL! ].
I didn't know that a Car is a special kind-of-an
Engine, even if knowing that fact would be restricted
only for private interface of the Car class.
It's ridiculous!

I think the more adequate example would be:

class IllegalEmployee : private Employee

;D
The IllegalEmployee knows that he is a kind of Employee.
He is able to do what other legal employers do.
But for wider public he is not an Employee He
doesn't confess that he is Maybe some his friend
class EmployeesFriend [;D] could make use of this
fact, but not the others

 

[Victor Bazarov]

"(...)
The 'Car has-a Engine' relationship can also be expressed
using private inheritance:

class Car : private Engine
(...)"

WHAT?!
What sense makes the above?
The "has-a" relationshit is evidently a composition.

So? The object is composed of its base class subobjects and data
members. If I want to add an entity to my object, why couldn't
I use inheritance?

If someone think different, let he try to think if
the Car could have more than one engine. I haven't seen
that kind of car, but if we do the same with the plane,
we'll see that it could have more engines than one.
How one could express that with use of [private] inheritance??

Those are different engines, are they not? You have to have
a way to identify engines, no? You can derive different classes
for the "left" and "right" engine (or however else you identify
them), and inherit from those.

It's impossible, ant that's the reason why it should be
done with use of composition.

"Composition" and "private inheritance" are orthogonal concepts.
You cannot set them _against_ each other.

There is other thing wrong in that example.
It assumes that for the Car class's implementation
the Engine is an ancestor. So, from the perspective
of the implementation, Car is-a Engine [WTF?? LOL! ].
I didn't know that a Car is a special kind-of-an
Engine, even if knowing that fact would be restricted
only for private interface of the Car class.
It's ridiculous!

I think you're (like many others before you) confuse some
OO principles (and their applicability) with C++ language
features that have never been intended to serve as the direct
implementation of those principles. Just like many others you
probably assume C++ an OOP language, which it isn't.

V

 

[James Kanze]

Inheritance always means "IS A" relationship.
E.g. "Porshe IS A Car".
It means that Porshe could do all the things that
all Cars can do.

C++ inheritance is an implementation technique in C++, to be
used when appropriate. It doesn't "mean" anything, except that
it was a convenient implementation technique. There is not
necessarily a one to one relationship between C++ inheritance
and OO derivation. It is exceedingly rare, of course, for OO
derivation to be implemented with anything other than
inheritance in C++, but I imagine that there are cases. And it
is quite common for C++ inheritance to be used in cases other
than OO derivation.

In practice, if a class B "looks like" a base class (i.e. has a
virtual destructor and at least some virtual functions), and the
class D inherits publicly from B, then unless the documentation
explicitly states otherwise, it's probably safe to assume that
the inheritance is being used for OO derivation, and that the
LSP holds (although of course, the language itself makes no
guarantee). In general, one does not assume OO derivation, the
LSP or "isA" otherwise. (And of course, any explicite
documentation overrides all other considerations.)

Apply public inheritance when you want to describe
"IS A" relationshit to "whole world" By writing
class Porshe : public Car
you say to everyone: "Porshe IS A Car".
Thanks to public inheritance, which defines that
kind of relationship, it's possible to use derived
class [i.e. the Porshe] in every place where the
Car is accepted, because every Porshe is also a Car

Private inherintance could restrict the knowledge
about that family bonds only to the derived class.

That is *not* the conventional use. The "conventional"
statement is that public inheritance is inheritance of
interface, private inheritance inheritance of implementation.

The rest of the world will know nothing about that
relationship. The only thing which will be know that,
will be the class's implementation, and only it
will be able to use from that fact.

Some people also asks what is the difference between
private inheritance and composition. Some of them
sees no difference at all, because they focus only
on the fact that in both cases only the class's
implementation can use the contained/base class.
But there is one, very important difference:
overriding virtual methods. You cannot ovverride
a method of contained class, but you can do it
with methods of the [even privately] interface
derived from a base class.

Quite. Private inheritance implies a somewhat tighter binding
than composition, and the general rule for implementation is to
use composition when you can, and private inheritance when you
have to.

 

[SasQ]

So? The object is composed of its base class subobjects
and data members.

Technically, yes. But it's only "by accident" that
inheritance is implemented that way in C++.

If I want to add an entity to my object, why couldn't
I use inheritance?

Because using private inheritance for composition only to
exploit the fact that inherited object becomes a part of
the inheriting object, is some kind a "hack" for me.
Private inheritance is something more than simple
composition, as I've mentioned earlier. It has other
semantics, produces tighter dependency bound between
inheriting object and its base class, makes possibility
to ovverride virtual methods, doesn't allow multiple
instances of the base class contained in derived class etc.
For me those are way too different concepts to use it
interchangeably.

Those are different engines, are they not?

Those are different INSTANCES of the same Engine class.
They're not different CONCEPTS.

You have to have a way to identify engines, no?

Yes. But according to my previous observation [different
INSTANCES, not different CONCEPTS] I would express it
in the following way:

class Aeroplane
{
Engine leftOuter, leftInner, rightOuter, rightInner;
};

Try to do the same with inherintance ;J
Even if you derive the Engine class multiple times,
you won't be able to access to the particular engine
by unique name.

You can derive different classes for the "left" and
"right" engine (or however else you identify them),
and inherit from those.

My godess! So what BEHAVIOUR differs the left engine
from right engine?

"Composition" and "private inheritance" are orthogonal
concepts. You cannot set them _against_ each other.

I disagree. I treat private inheritance as a superset
of simple composition [it's something more].

I think you're (like many others before you) confuse
some OO principles (and their applicability) with C++
language features that have never been intended to
serve as the direct implementation of those principles.

So try to prove me my mistake

Just like many others you probably assume C++ an OOP
language, which it isn't.

C++ is a multiparadigm language. I know that it only SUPPORTS
OOP techniques, but it would be unlogical to support it
differently and in contradiction to the common sense ;J

 

[bourez]

And yet, private inheritance is sometimes called implementation
inheritance. It is equivalent to the composition with this
restriction: the relation must be one-to-one.

Could someone here tell me some links/pdfs/tutorials
to know about the difference between Private Inheritance
and Public Inheritance?

Inheritance always means "IS A" relationship.
E.g. "Porshe IS A Car".
It means that Porshe could do all the things that
all Cars can do.

Apply public inheritance when you want to describe
"IS A" relationshit to "whole world" By writing
class Porshe : public Car
you say to everyone: "Porshe IS A Car".
Thanks to public inheritance, which defines that
kind of relationship, it's possible to use derived
class [i.e. the Porshe] in every place where the
Car is accepted, because every Porshe is also a Car

Private inherintance could restrict the knowledge
about that family bonds only to the derived class.
The rest of the world will know nothing about that
relationship. The only thing which will be know that,
will be the class's implementation, and only it
will be able to use from that fact.

Some people also asks what is the difference between
private inheritance and composition. Some of them
sees no difference at all, because they focus only
on the fact that in both cases only the class's
implementation can use the contained/base class.
But there is one, very important difference:
overriding virtual methods. You cannot ovverride
a method of contained class, but you can do it
with methods of the [even privately] interface
derived from a base class.