Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!polyslo!ttwang
From: ttwang@polyslo.CalPoly.EDU (Thomas Wang)
Newsgroups: comp.lang.c++
Subject: Re: Why can't access control be used to disambiguate between base class members?
Message-ID: <13073@polyslo.CalPoly.EDU>
Date: 31 Jul 89 20:39:33 GMT
References: <2408@ginosko.samsung.com>
Reply-To: ttwang@polyslo.CalPoly.EDU (Thomas Wang)
Distribution: na
Organization: Cal Poly State University -- San Luis Obispo
Lines: 44

In article <2408@ginosko.samsung.com> fialli@ginosko.samsung.com (Joe Fialli) writes:
>I was wondering if anyone could offer an explaination for the
>following rule taken from the AT&T C++ Release 2.0 Product Reference
>Manual,Section 10.1.1, page 65.

>   (In the context of multiple base classes,) Access to base class members 
>   must be unambiguous. ... The check for ambiguity take place before access 
>   control and before type checking.

>	class A{ public: int a;	};
>       class B{ private:int a; };
>       class C : public A, public B {};

>        void g(C* pc)
>        {
>	    pc->a = 1;   //error, ambiguous: A::a or B::a ?
>        }

In my opinion, the use of access restrictions to make the reference
unambiguous is a hack.

The real solution is name conflict resolution, as shown below:

class A{ public: int a; };
class B{ private:int a; };
class C : public A, public B
{ alias A::a = A_a; };

void g(C* pc)
{
  pc->A_a = 1; // OK, we know it refers to class A
}

We need name conflict resolution, because class A may be supplied by AT&T, and
class B may be supplied by IBM.  Both classes come with compiled object code
and class header.  Joe the programmer then must make class C from class A and
class B.  In this case, the modification and re-compilation of both class A
and class B are impossible.

I hope to see this feature in C++ version 3.0.  I am not holding my breath.

 -Thomas Wang (Ah so desu ka!)

                                                     ttwang@polyslo.calpoly.edu