Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!portal!cup.portal.com!Tim_CDC_Roberts
From: Tim_CDC_Roberts@cup.portal.com
Newsgroups: comp.lang.c++
Subject: Re: Why can't access control be used to disambiguate between ba
Message-ID: <20951@cup.portal.com>
Date: 2 Aug 89 18:57:06 GMT
References: <2408@ginosko.samsung.com> <13073@polyslo.CalPoly.EDU> <9716@alice.UUCP>
Organization: The Portal System (TM)
Lines: 37

In article <9716@alice.UUCP>, ark@alice.UUCP (Andrew Koenig) writes:
> In article <13073@polyslo.CalPoly.EDU>, ttwang@polyslo.CalPoly.EDU
> (Thomas Wang) writes:
> > 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 don't quite see why this causes a problem.

I have to agree with Mr Wang.  It seems to me that a compiler should be
able to disambiguate the following modification of your example:

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

    void foo()
    {
        A a;
        B b;
        C c;

        a.x = 3;                // Incorrect -- private
        b.x = 4;                // OK
        c.x = 5;                // Since c.A::x does not exist, as far
                                // as C is concerned, this should NOT
                                // be ambiguous and should be allowed.
        c.A::x = 5;             // Incorrect -- private
        c.B::x = 5;             // OK
    }

Tim_CDC_Roberts@cup.portal.com                | Control Data...
...!sun!portal!cup.portal.com!tim_cdc_roberts |   ...or it will control you.