Re: Friends and Visual C++ Express 2005
On Sep 22, 1:30 am, Barry <dhb2...@gmail.com> wrote:
t wrote:
I'm not sure. There are lines in the code I gave involving "a2.x"
that are compiling that I don't think should be compiling. It seems
like the Visual C++ compiler is using more lenient friendship rules.
The example in Lippman is different. I'll just type it out.
See "// my comment:" for my comments below. All other comments
are Lippman's.
Well, use the former example rather than this one
void g(A a, A2 a2)
{
a2.x; // compiles, but shouldn't ?
}
here a2.x is can be interpreted this way:
int A::*pm = &A::x; // (1)
a2.*x; // (2)
then the access control actually takes place on (1),
since g is a friend of A, then taking a private pointer to member of A
is legal.
So, to conclude, when we do inheritance, the members of the base class
are not members of the derived class. The derived class only *inherits*
them.
Actually, the members of a base class inherited by a derived class,
are in fact members of the derived class as well:
"Unless redefined in the derived class, members of a base class
are also considered to be members of the derived class."[=A710/1]
So, in this example, B has two potential routes to get to A2::x -
either through A2::A2::x or via A2::A::x. Since B is a friend of A's,
it can reach A2::x through A::x (since the "x" in either A or A2 is
the same member). And whenever there is more than one ways to access a
member of a class, a C++ compiler must choose the one that grants the
most access - which in this case is through B's friend, A.
Greg