[comp.lang.c++] Ambiguity and Access Control

dsouza@mcc.com [Desmond D'Souza] (11/18/89)

In 2.0, is ambiguity checked independently (before) access control.
If so, WHY ?

Given:
	class LIB_CLASS { private: int i ; } ; 
in some pre-compiled library.

Given that there is NO way I can access/use "LIB_CLASS::i", it should
be quite invisible to me.

However, the following happens when I try to use LIB_CLASS:

	class B1 { public: int i ; } ; 	// my int "i"

	class D : public B1, public LIB_CLASS
	 { void foo () { i = 0 ; }
		// ERROR! "i" is ambiguous
	 } ;

Of course, the same happens if I derive :privately from LIB_CLASS.

Seems counter intuitive to the purpose of ":private" members, which should
be quite invisible and should not cause name conflicts.

Desmond.
 Desmond D'Souza, MCC CAD Program | ARPA: dsouza@mcc.com | Phone: [512] 338-3324
 Box 200195, Austin, TX 78720 | UUCP: {uunet,harvard,gatech,pyramid}!cs.utexas.edu!milano!cadillac!dsouza

ark@alice.UUCP (Andrew Koenig) (11/18/89)

In article <4051@cadillac.CAD.MCC.COM>, dsouza@mcc.com [Desmond D'Souza] writes:

> In 2.0, is ambiguity checked independently (before) access control.
> If so, WHY ?

For one thing, it makes debugging much easier if the language
has the property that

	making every member of a class public
	does not affect the behavior of the program.
-- 
				--Andrew Koenig
				  ark@europa.att.com

strange@cbnewsl.ATT.COM (philip.e.brown) (11/20/89)

	In article <4051@cadillac.CAD.MCC.COM> dsouza@mcc.com writes:
	>
	>
	>In 2.0, is ambiguity checked independently (before) access control.
	>If so, WHY ?

Yes.

Access could easily be checked before ambiguity if C++ only
supported class data members (one name, one member).  However,
C++ also has function members (one name, many members).

Currently, lookup applies to a name, whereas access control
applies to a member.  Bridging this gap are the rules for
overloaded function matching.

So, you have something like
    (1) name lookup
    (2) matching
    (3) access control

where "matching" for a data member is a no-op.  The ambiguity
check currently happens at the end of (1).

The question is then,
    "Why can't all three steps be combined into one to avoid ambiguities?"

Basically, you can't always do the matching before the
ambiguity check.  Consider

    class C {
	int f(int);
    public:
	int f(double);
    };

    int (C::*pmf)(int) = &C::f;

The expression "C::f" must provide an unambiguous name even
though the matching and access check cannot be done until
the initialization of "pmf".

--------

Phil Brown
strange@attunix.att.com