jkanze@otelo.ibmmail.com wrote:
> ...
> But doesn't this sort of
> defeat the purpose of private inheritance?  Private inheritance isn't
> meant to represent an isA relationship.

Huh?  Inheritance does mean an IsA relationship, private or
otherwise.  Or does C++ grant some special meaning to private
inheritance that doesn't apply to inheritance in general?

-- David R. Tribble, david.tribble@noSPAM.central.beasys.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david.tribble@central.beasys.com> wrote:
: jkanze@otelo.ibmmail.com wrote:
: > ...
: > But doesn't this sort of
: > defeat the purpose of private inheritance?  Private inheritance isn't
: > meant to represent an isA relationship.

: Huh?  Inheritance does mean an IsA relationship, private or
: otherwise.  Or does C++ grant some special meaning to private
: inheritance that doesn't apply to inheritance in general?

Vice versa. There is an implicit conversion in C++:
pointer/reference to Derived ==> pointer/reference public Base.
Therefore you are obliged to maintain IS_ALMOST_A (Tm) relationship
between the two. There is no such implicit conversion for private
Base. Therefore you are not obliged to maintain such a relationship.
But you can, if you want to.

A user can still use old-style cast to cast to a ptr/ref to private
Base, but it would be his own fault.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>
> jkanze@otelo.ibmmail.com wrote:
> > ...
> > But doesn't this sort of
> > defeat the purpose of private inheritance?  Private inheritance isn't
> > meant to represent an isA relationship.
>
> Huh?  Inheritance does mean an IsA relationship, private or
> otherwise.  Or does C++ grant some special meaning to private
> inheritance that doesn't apply to inheritance in general?
>

I strongly disagree  with you. Indeed I think C++ grants special meaning
to private inheritance. Since it is not allowed to convert a derived
class object into a base class object, it certainly does not mean 'isA'.
Private inheritance means -- and IMO it should only be used in this
purpose -- 'is-implemented-in-terms-of'.

My 0.02
       Philippe.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 [Moderator's note: this thread seems to have drifted away from
 standards issues.  I have crossposted to comp.lang.c++.moderated
 and redirected followups.
  -moderator of comp.std.c++ (fjh).]

Philippe Nobili <pnobili@imaginet.fr> schrieb im Beitrag
<351B680A.5F14@imaginet.fr>...
> David R Tribble wrote:
> >
> > jkanze@otelo.ibmmail.com wrote:
> > > ...
> > > But doesn't this sort of
> > > defeat the purpose of private inheritance?  Private inheritance isn't
> > > meant to represent an isA relationship.
> >
> > Huh?  Inheritance does mean an IsA relationship, private or
> > otherwise.  Or does C++ grant some special meaning to private
> > inheritance that doesn't apply to inheritance in general?
>
> I strongly disagree  with you. Indeed I think C++ grants special meaning
> to private inheritance. Since it is not allowed to convert a derived
> class object into a base class object, it certainly does not mean 'isA'.
> Private inheritance means -- and IMO it should only be used in this
> purpose -- 'is-implemented-in-terms-of'.
>
I (some sort of) disagree. I find it suitable to :

class School {} workplace, child_education;
class Home {} own, foreign;
class Female: Teacher, Mom {} female;

workplace.enter( female.asTeacher() ); // acting for pupils
own.enter( female.asMom() ); // acting for own Children
and even
foreign.enter( female.asTeacher() ); // acting for as pupils
foreign.enter( female.asMom()  ); // babysitting

Thus 'female' cannot auto-converted to Mom in context school
and not auto auto-converted to Teacher in context Home, but
remains the same identity.
And in certain well known environments, female can still grant
explicit conversion.
Virtual calls are preserved :)

Any comments ?
 --ALfred




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article 1@nnrp1.dejanews.com, jkanze@otelo.ibmmail.com writes:
>I'd just like a confirmation that the following program is legal:
>
>    #include <stddef.h>
>
>    class B {} ;
>    class D : public B {} ;
>
>    class BPtr { public: operator B*() ; } ;
>    class DPtr : private BPtr { public: operator D*() ; } ;
>
>    bool
>    f( DPtr p )
>    {
> return ( p == NULL ) ;
>    }
>
>I have tried it on two compilers (VC++ and CSet++), and both declare
>ambiguous conversion in the line with the return.  IMHO, since the
>derivation is private, the compiler shouldn't see the conversion
>operator in the base class, so the conversion shouldn't be ambiguous.

But overload resolution is applied regardless of access; access is
checked only after an unambiguous match is found.

Draft Standard chapter 11 "Member access control", paragraph 4:

"It should be noted that it is access to members and base classes that is
controlled, not their visibility. Names of members are still visible, and
implicit conversions to base classes are still considered, when those
members and base classes are inaccessible. The interpretation of a given
construct is established without regard to access control. If the
interpretation established makes use of inaccessible member names or
base classes, the construct is ill   formed."

Chapter 13.3 "Overload resolution", paragraph 1:

"[Note: the function selected by overload resolution is not guaranteed
to be appropriate for the context. Other restrictions, such as the
accessibility of the function, can make its use in the calling context
ill-formed.]"

I'd say the program is invalid, and the compilers are correct.

---
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6es65h$7t4@engnews1.Eng.Sun.COM>,
  clamage@Eng.Sun.COM wrote:
>
> In article 1@nnrp1.dejanews.com, jkanze@otelo.ibmmail.com writes:
> >I'd just like a confirmation that the following program is legal:
> >
> >    #include <stddef.h>
> >
> >    class B {} ;
> >    class D : public B {} ;
> >
> >    class BPtr { public: operator B*() ; } ;
> >    class DPtr : private BPtr { public: operator D*() ; } ;
> >
> >    bool
> >    f( DPtr p )
> >    {
> > return ( p == NULL ) ;
> >    }
> >
> >I have tried it on two compilers (VC++ and CSet++), and both declare
> >ambiguous conversion in the line with the return.  IMHO, since the
> >derivation is private, the compiler shouldn't see the conversion
> >operator in the base class, so the conversion shouldn't be ambiguous.
>
> But overload resolution is applied regardless of access; access is
> checked only after an unambiguous match is found.

I knew I'd forgotten something, but I couldn't figure out what.

   [Quotes from draft deleted...]

> I'd say the program is invalid, and the compilers are correct.