Re: access specifiers & class inheritance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8 April 2013 11:09, scalpel4k wrote:
> Hallo experts,
>
> I have a little problem with access specifiers for class inheritance, which can be demonstrated in the following example.

This is a general C++ question, not specific to GCC, so this isn't
really the right place to ask it.


>>>> EXAMPLE >>>
>
> class A {
> protected:
>   int i = 0;
> };
>
> class B : private A {
> private:
>   int getValue() {
>     return i;
>   }
> };
>
> class C : private A, public B {
> private:
>   int getValue() {
>     return i;
>   }
> };
>
> <<< EXAMPLE <<<
>
> This will eventually cause a compiler error, because allegedly in class C parameter i is ambiguous.
>
> The standard clearly says (clause 11.2) that in class B all members of class A are privat to B, so they should not be visible to class C.

Access control in C++ does not affect visibility.

> The problem seems to come from clause 10.2 in the specification that says that name resolution runs before(!) visibilty rules are applied.

Yes, that's how C++ works.


> I would say my example is slightly similar to the example given in 11.6, but I assume the virtual keyword makes some difference here. Am I right? Otherwise, I wonder why this should be ok, since f() would also be resolved twice.

The virtual keywod means there is only one base class of type W, so
there is no ambiguity.

> Can anybody explain why I can have the same symbol when it's declared private in the class scope, but I can't if I make it private through inheritance? This is an ambiguity I don't understand.

I don't understand what you mean by "have the same symbol when it's
declared private in the class scope"

If you mean that it works if you define C::i then it's because name
lookup stops when it finds C::i and doesn't look in the base classes,
so doesn't find the two ambiguous definitions of A::i caused by two A
bases.




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux