fialli@ginosko.samsung.com (Joe Fialli) (07/31/89)
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.
The following shorten example taken from the reference manual illustrates
the intent of this rule.
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 ?
}
I feel that access control rules could have been used to disambiguate
the reference to data member a. Data member a is declared private
in class B; therefore, a is not accessible in function g. Why should
the user have to explicitly disambiguate this reference when
a reference to pc->(B::a) would result in an error message stating
that member a is not visible ?
Additionally, I feel this rule pollutes the name space for accessing
members acquired via multiple base classes.
For example:
class UsefulClassFromALibrary{ private: void common_name( void );
public: void public_name( void );
};
class UserClass { public: void common_name( void );
};
classMultDerived : public UsefulClassFromALibrary, public UserClass {};
void foo( void )
{
MultDerived C;
C.common_name(); // error, ambiguity between
// private UsefulClassFromALibrary::common_name();
// and
// public UserClass::common_name();
}
This example shows how there can easily be name clashes between
private members of classes taken from some library of useful classes
and a user created classes. I would think one advantage to declaring
members private to a class is to keep the name space to be inherited
by classes derived from this library class as small as possible.
In summary, I was just wondering why access control and type checking
can not be used to disambiguate access to base class members?ttwang@polyslo.CalPoly.EDU (Thomas Wang) (08/01/89)
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
ark@alice.UUCP (Andrew Koenig) (08/01/89)
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. There's nothing wrong with having members with the same name in two different base classes as long as you don't try to access one of those members in an ambiguous way. If they're private, presumably you won't. Example: struct A { int x; }; struct B { int x; }; struct C: A, B { }; void foo() { A a; B b; C c; a.x = 3; // OK b.x = 4; // OK c.x = 5; // error -- ambiguous c.A::x = 5; // OK c.B::x = 5; // OK } Of course, if C has a member named x, then C::x is unambiguous. -- --Andrew Koenig ark@europa.att.com
jima@hplsla.HP.COM (Jim Adcock) (08/02/89)
// 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 {public: int& A_a; C():A_a(A::a){}};
void g(C* pc)
{
pc->A_a = 1; // OK, we now know it refers to class A,
// you can stop holding your breath. :-)
}ark@alice.UUCP (Andrew Koenig) (08/02/89)
In article <6590221@hplsla.HP.COM>, jima@hplsla.HP.COM (Jim Adcock) writes: > // 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 {public: int& A_a; C():A_a(A::a){}}; > void g(C* pc) > { > pc->A_a = 1; // OK, we now know it refers to class A, > // you can stop holding your breath. :-) > } The following variation works too, which is particularly useful because it allows C::a to be used. class A{ public: int a; }; class B{ private:int a; }; class C : public A, public B {public: int& a; C():a(A::a){}}; void g(C* pc) { pc->a = 1; // OK, we now know it refers to class A } The one disadvantage of this scheme is that it introduces an extra level of indirection: C::a (or C::A_a in the previous example) is actually stored in memory as a pointer and that pointer is dereferenced each time C::a is used. Of course, if enough people do this, compiler writers will start optimizing away the reference member in such cases and the overhead will vanish. -- --Andrew Koenig ark@europa.att.com