[Moderator's note: this discussion is beginning to move away from the
C++ standard and towards C++ programming.  If you respond to this article,
and if you think that another newsgroup would be more apropriate, you
should edit the newsgroups line.  mha]

I use private in the sense: reserved for friends, and do use friends a
lot, to dedicate interfaces.

Friendship allows me to implement "behaviour specification" instead of
merely "signature specification".

With this in mind, a friend abstract base class IS typically the
interface I provide to a given resource: you use it by inheriting from
it. It tyipcally provides with public non virtual functions, which are
implemented to access some private members of the resource class, and
some virtual members of the friend class.

This way, I can statically insure that certain preconditions are
fulfilled at the point of accessing the resource members, yet not
overspecify the dependencies on the users.

In this scheme, I do use protected inheritance in the resource class.

An other example of a similar, yet different, use of
friendship/protected inheritance is this of reference counting through
handles: I have a base class with members to maintain the count, and
make it accessible to my friend handles, as well as to
specializations.

All this makes sense because I use inheritance for separating
interface from implementation, which frees the public/private pair
from the burden of supporting these semantics.
--
+---------------------------------------------------------------------------+
| Marc Girod - Nokia Telecommunications     Phone: +358-0-511 27703         |
| Kilo RD 4 - P.O. Box 12                     Fax: +358-0-511 27432         |
| SF-02611 Espoo 61 - Finland            Internet: marc.girod@ntc.nokia.com |
|        X.400: C=FI, A=Elisa, P=Nokia Telecom, SUR=Girod, GIV=Marc         |
+---------------------------------------------------------------------------+


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

[Moderator's note: this discussion is beginning to move away from the
C++ standard and towards C++ programming.  If you respond to this article,
and if you think that another newsgroup would be more apropriate, you
should edit the newsgroups line.  mha]

Herb Sutter wrote:
 On a wider note, hasn't anyone else come across
> situations where protected inheritance was The Right Thing To Do(tm)?  While
> it's true that its use is rare, I find it hard to believe that I should be the
> only one to come across such design situations.

I use protected inheritance to perform "implementation inheritance" which I
want to expose to subclasses but not to clients of the class. Eg: clients of
the class see the class' public interface while the implementation and
subclasses see the public interface of the implementation class. Its a useful
way of mixing in implementation and services which are useful for derived
classes, and although I haven't used it extensively when I needed it I was glad
it was there.

In summary, I'd say that it is a feature of C++ which allows one to express
and abstract out reusable *behaviour* or *implementation*, rather than express
data abstraction and polymorphism.

Cheers,
 Nat.
--
+-------------------------------------------+---------------------------------+
| Name:   Nat Pryce MEng ACGI               | Mail:  Department of Computing, |
| Email:  np2@doc.ic.ac.uk                  |        Imperial College,        |
| Tel:    +44 (0)171 594 8394 (Direct Dial) |        180 Queen's Gate,        |
| Fax:    +44 (0)171 581 8024               |        London SW7 2BZ,          |
| WWW:    http://www-dse.doc.ic.ac.uk/~np2  |        United Kingdom           |
+-------------------------------------------+---------------------------------+


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

"What is protected inheritance?"

Through experience, I now know the answer.  However, by far the most common
(and wrong) idea I keep hearing is that it was 'put in for completeness' since
we already have public and private inheritance, but that no one really knows
what it's good for.  All the major books barely mention it.  In more or less
chronological order:

Meyers ("Effective C++", 1992) says only: "no one seems to know what protected
inheritance (a latecomer on the scene anyway) is supposed to mean." (pg 120)

Stroustrup (D&E, 1994) has only "inheritance, public" and "inheritance,
private" in the index.

Ellis and Stroustrup (ARM, 1994 reprint) give it two lines in Section 19,
informing that the committees have voted it in.  The same two lines are given
in Stroustrup (C++PL2, 1993) section a.1.  I can't find even an index entry in
other books around this period, such as Coplien ("Advanced C++", 1992).

Carroll and Ellis ("Designing and Coding Reusable C++", 1995) says only: "(You
might notice that we do not discuss protected derivation.  Whether protected
derivation is useful is debatable.)" (pg 49)

The best I've found is Cline's and Lomow's ("C++ FAQs", 1995) brief mention in
their book's FAQ #449, saying that protected inheritance is for when you want
further-derived classes to have access to the base class' protected interface.
 Fine, that's part of it, and there are no examples and no further English
discussion of "what protected inheritance means" and when you'd use it.  In
contrast, I've recently come upon two detailed examples in my own work where
it is both necessary and elegant.

Here's the upshot and my question(s): For what specific reasons did the
standards committees include protected inheritance?  Was it only for
completeness, or were specific examples where protected inheritance was
necessary known at the time?  On a wider note, hasn't anyone else come across
situations where protected inheritance was The Right Thing To Do(tm)?  While
it's true that its use is rare, I find it hard to believe that I should be the
only one to come across such design situations.

If the above literature really reflects the state of the industry, I should
write a few articles.  However, before I start wasting time on that, I'd
rather find out that protected inheritance is after all understood, but just
somehow hasn't made it into the literature.

Thanks in advance,

Herb


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herb Sutter (herbs@connobj.com)

Connected Object Solutions     2228 Urwin - Suite 102     voice 416-618-0184
http://www.connobj.com/      Oakville ON Canada L6L 2T2     fax 905-847-6019


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article c95@steel.interlog.com, herbs@interlog.com (Herb Sutter) writes:
>
>"What is protected inheritance?"

>Through experience, I now know the answer.  However, by far the most common
>(and wrong) idea I keep hearing is that it was 'put in for completeness' since
>we already have public and private inheritance, but that no one really knows
>what it's good for.

The only reason for protected inheritance I ever saw or heard was for
symmetry and because there seemed to be no reason to disallow it.

>...  In
>contrast, I've recently come upon two detailed examples in my own work where
>it is both necessary and elegant. ...

>If the above literature really reflects the state of the industry, I should
>write a few articles.

Please do. I always find it a bit embarassing when teaching C++ to
describe protected inheritance as a solution in search of a problem.

---
Steve Clamage, stephen.clamage@eng.sun.com




---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]