Base class pointers and private inheritance

[Dave Theese]

Hello all,

The example below demonstrates proper conformance to the C++ standard.
However, I'm having a hard time getting my brain around which language rules
make this proper...

The error below *should* happen, but my question to the community is *why*
does it happen? Any answer will be appreciated, but a section and paragraph
number from the C++ Standard would be especially appreciated.

Thanks to all!
Dave

P.S. I do understand the conceptual difference between public / private
inheritance (i.e. "is-a" vs. "has-a").

struct b {};
struct d: private b {};

int main()
{
// By itself, "new d" is fine.
new d;

// This, however, yields the following error:
// conversion from d* to b* exists but is inaccessible
b *ptr = new d;
}

[Gianni Mariani]

Re: Base class pointers and private inheritance

Dave Theese wrote:[color=blue]
> Hello all,
>
> The example below demonstrates proper conformance to the C++ standard.
> However, I'm having a hard time getting my brain around which language rules
> make this proper...
>
> The error below *should* happen, but my question to the community is *why*
> does it happen? Any answer will be appreciated, but a section and paragraph
> number from the C++ Standard would be especially appreciated.
>
> Thanks to all!
> Dave
>
> P.S. I do understand the conceptual difference between public / private
> inheritance (i.e. "is-a" vs. "has-a").
>
> struct b {};
> struct d: private b {};[/color]

What you have said here in English:

A "d" IS-A "b" but don't let anything but "d" use me as a "b".
[color=blue]
>
> int main()
> {
> // By itself, "new d" is fine.
> new d;
>
> // This, however, yields the following error:
> // conversion from d* to b* exists but is inaccessible
> b *ptr = new d;[/color]

Here you try to use a "d" as a "b" in direct violation of what you said
above.

So what's the problem ?

[White Wolf]

Re: Base class pointers and private inheritance

Dave Theese wrote:[color=blue]
> Hello all,
>
> The example below demonstrates proper conformance to the C++ standard.
> However, I'm having a hard time getting my brain around which
> language rules make this proper...
>
> The error below *should* happen, but my question to the community is
> *why* does it happen? Any answer will be appreciated, but a section
> and paragraph number from the C++ Standard would be especially
> appreciated.[/color]
[SNIP]

In 4.10 Pointer Conversions, Paragraph 3 Simon says:

"An rvalue of type "pointer to cv D," where D is a class type, can be
converted to an rvalue of type "pointer to cv B," where B is a base class
(clause 10) of D. If B is an inaccessible (clause 11) or ambiguous (10.2)
base class of D, a program that necessitates this conversion is illformed."

--
WW aka Attila

[Kevin Goodsell]

Re: Base class pointers and private inheritance

Dave Theese wrote:
[color=blue]
> Hello all,
>
> The example below demonstrates proper conformance to the C++ standard.
> However, I'm having a hard time getting my brain around which language rules
> make this proper...
>
> The error below *should* happen, but my question to the community is *why*
> does it happen? Any answer will be appreciated, but a section and paragraph
> number from the C++ Standard would be especially appreciated.
>
> Thanks to all!
> Dave
>
> P.S. I do understand the conceptual difference between public / private
> inheritance (i.e. "is-a" vs. "has-a").[/color]

I don't believe such a conceptual difference exists. Inheritance always
models "is a" relationships, in my opinion. The only difference is, who
gets to know about the relationship and exploit it? In public
inheritance, everyone can. In private inheritance, only members and
friends can.
[color=blue]
>
> struct b {};
> struct d: private b {};
>
> int main()
> {
> // By itself, "new d" is fine.
> new d;[/color]

This isn't really "fine"... it's a memory leak.
[color=blue]
>
> // This, however, yields the following error:
> // conversion from d* to b* exists but is inaccessible
> b *ptr = new d;[/color]

Indeed. Function main() is not a member or friend of d, therefore may
not do this conversion.

Also, though it's not strictly necessary, it's a good idea to have a
return statement here:

return 0;
[color=blue]
> }
>
>[/color]

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Jerry Coffin]

Re: Base class pointers and private inheritance

In article <WtQ1b.7710$QT5 .2690@fed1read0 2>, cheeser_1998@ya hoo.com
says...[color=blue]
> Hello all,
>
> The example below demonstrates proper conformance to the C++ standard.
> However, I'm having a hard time getting my brain around which language rules
> make this proper...
>
> The error below *should* happen, but my question to the community is *why*
> does it happen?[/color]

Because you've asked for it to happen. Private inheritance means
exactly that: the relationship between the derived and the base class is
not visible to the outside world, so the conversion from derived to base
that's allowed with public inheritance isn't allowed with private
inheritance.
[color=blue]
> P.S. I do understand the conceptual difference between public / private
> inheritance (i.e. "is-a" vs. "has-a").[/color]

A "has-a" relationship is normally expressed by aggregation -- i.e. one
object containing an instance of another. The usual description for
private inheritance is "is implemented in terms of". E.g. a stack being
implemented in terms of a vector -- a stack doesn't support the full
interface of a vector, so we can't use public inheritance. At the same
time, it would be wasteful to use aggregation, because all the data
needed for a stack is already contained in a vector.

This is fairly typical: private inheritance is often used when the base
object includes _more_ functionality than needed, and the private
inheritance is used to create a more limited interface (directly
contrary to public inheritance, which means the derived object must
support at least the full base interface, and may add more).

--
Later,
Jerry.

The universe is a figment of its own imagination.