Re: Sanity check: public/private
Carlos Moreno wrote:
Jiang wrote:
For following example,
struct B
{
int t;
};
struct D1 : private B // private inheritance (hold-a)
{
D1(){ t = 0; }
};
struct D2 : public D1
{
D2(){ t = 0; } // error, B::t is not accessible.
};
So, again private and public make difference here.
If I understand correctly, this example is not valid with respect
to my question -- sure, private and public make a difference, but
is not that what counts; I'm starting with a code *that compiles*;
so, if I haev a privately inherited base class, then my code would
only do what it is allowed to do. *Then* I replace the privately
inherited to a publicly inherited. There shouldn't be any error
now: I'm eliminating restrictions, so whatever I was able to do
before, I'm able to do now, and more (except that, again, my
question describes a situation where I will not do anything more,
since I will *only* change the private keyword to public)
Well, my point is the private inheritance constructs a
"hold-a" relationship while public inheritance yields a
"is-a" relationship. If you replace private with public,
you create a inheritance chain, which is not available
in the original configuration.
Please check the nice examples purposed by Kanze
and Falk.
Actually I do not known any compilers really treat
private and public member differently, because
access specifiers are purely logical constructs.
My thinking exactly. Private does not determine behaviour; it
simply places semantic restrictions on what the program is
allowed to do, not on the behaviour resulting from what the
program does do.
Not true for case 2. My above comment was based on case 1.
And even for case 1, it is pretty valid that the compilers can
allocate private members in higher address, and put all public
members in other region, because here the allocation order
is unspecified behavior according to the standard.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]