Re: C++: current 2.96 now too strict at access control

["Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>]

> Things possible for global functions should
> not be impossible for any member function.

Thanks for your bug report. I'm not so sure it is a bug in gcc. I
think your code is ill-formed, and should be corrected as

struct A {};

struct B : private A {};

struct C : B {
  void f()
  {
    C c;
    ::A a;             //should pass
    ::A* ap = (::A*) &c; //should pass
  }
};

My line of reasoning (and apparently gcc's as well) is the following:

1. The name of a class is inserted as an implicit public member into
   each class (9, [class]/2). So A is inserted into A (publically).

2. Name lookup in a derived class finds names in the base class before
   it finds names in enclosing scopes. So the lookup 

3. A member inherited from a private base class is private in that
   class, whether it was private, public, or protected in the base
   (11.2, [class.access.base]/1). So A is private in B.

Consequently, A is private in C, and access is denied. Please also
consider the note in 11.2/3, which says

# A member of a private base class might be inaccessible as an
# inherited member name, but accessible directly.

So if you access A directly (i.e. as ::A), the compiler should (and
does) accept the code.

Also note that the example in 11.2/3 then makes the same error as you
did, and Core Issue 142
(http://www.informatik.hu-berlin.de/~loewis/corer8.html#142) proposes
to correct the example appropriately.

If you question this line of reasoning, please discuss it in one of
the public C++ fora first, eg. comp.lang.c++.moderated, or
comp.std.c++ (that sentence just got added into my gcc-bugs response
template :-).

Regards,
Martin