Re: What exactly is considered inherited from a base class?
On 2011-05-13 01:52:56 -0400, cpp4ever said:
On 13/05/11 08:04, Pete Becker wrote:
On 2011-05-12 11:26:33 -0400, cpp4ever said:
On 12/05/11 16:48, Pete Becker wrote:
On 2011-05-12 00:35:06 -0400, cpp4ever said:
On 12/05/11 01:06, Pete Becker wrote:
On 2011-05-11 12:07:28 -0400, Kris Prad said:
This is a Java site, yet applicable here:
http://download.oracle.com/javase/tutorial/java/IandI/subclasses.html
The site starts with a blanket statement like:
"A subclass inherits all the members (fields, methods, and nested
classes) from its super class." ---------------- (1)
and later on after a few paragraphs, narrows it down to:
=93Private Members in a Super class:
A subclass does not inherit the private members of its parent class.
However, if the super class has public or protected methods for
accessing its private fields, these can also be used by the
subclass.=94
-------------- (2)
Umm, no. This talks about something that's fundamentally different
from
the way that C++ works.
My question: Are private members of a base class considered
inherited
or not? (That they are accessible via public accessor methods is
beside the point.)
My understanding: If the inheritance is conditional upon access
("data
hiding" aspect), then (2) is applicable - private members are not
inherited. Otherwise (1) is applicable. My understanding is that
(2)
prevails. Data hiding and inheritance are orthogonal concepts in
theory, but bound together in practice. I may be wrong in
interpreting
like this.
This may be splitting hairs as far as programming is concerned =96
one
just knows how they work, but the difficulty is in communicating
these
as concepts.
In C++, all members are inherited. Try it. Write a base class with
private members that declares its derived class as a friend.
Personally I avoid using friend on the basis it defeats the whole
point
of information hiding.
<shrug> The point of my message was to suggest a way to explore how
inheritance works, not to recommend a general coding approach.
I mean't no offense, but the original question was concerned with
inheritance, public, proteceted and private, which becomes irrelevant
for friends of a class.
No, it's not irrelevant. If private members aren't inherited then their
names simply don't exist in the derived class (that's how it works in
Java). If they are inherited, then a derived class that's a friend can
access them. The effect of trying to access a private member of a class
from a derived class that's not a friend is left as an exercise for the
reader. As I said in my original message, "Try it".
Agreed, (that all the members need to be inherited), but private
data
members and functions may also be used to implement the the class
objects functionality, maintaining it's current state, and therefore
they should be privately available to provide controlled maintenance of
the base objects current state via interfaces. IMHO this is a far better
approach to inheritance,
Far better than what? Once again, what I suggested was a way to
*explore* how inheritance and access control interact. It was not a
coding guideline, and comments about better ways to code, while
interesting, are completely irrelevant to the point that I was making.
Unless, of course, your point is that *even when exploring*, coding
guidelines should be rigidly adhered to. I simply don't agree.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]