[gnu.g++.bug] g++ 1.32 is lax on protection

schmidt%siam.ics.uci.edu@PARIS.ICS.UCI.EDU ("Douglas C. Schmidt") (01/26/89)

According to page 3 of the USENIX Lime book, the following program
is incorrect:

----------------------------------------
class X {
protected:
   int prot;
};

class Y : public X {
   void mf ();
};

void Y::mf()
{
   prot = 2;
   X a;
   a.prot = 3; // error, prot is protected and a is not a Y!
   X *p = this;
   p->prot = 3; // error, prot is protected and p is not a pointer to Y!
}
----------------------------------------

However, g++ 1.32 does not complain about this.

Doug

beshers%carcvax.brc.uconn.edu@PARIS.ICS.UCI.EDU (George Beshers) (01/26/89)

I thought that was the point of `protected' vs. `private'.  If you change
to private you get the error.

				beshers@carcvax.brc.uconn.edu

schmidt%crimee.ics.uci.edu@PARIS.ICS.UCI.EDU ("Douglas C. Schmidt") (01/27/89)

 > I thought that was the point of `protected' vs. `private'.  If you change
 > to private you get the error.
 > 
 > 				beshers@carcvax.brc.uconn.edu

Hi,

I believe you're getting confused by the following (which is
admittedly weird at face value):

----------------------------------------
class foo {
protected:
   int i;
};

main () {
   foo bar;
   
   bar.i = 10; // error, protected members are not
               // visible to objects of the base
               // type.
}

g++ correctly says:

----------------------------------------
In function int main ():
test.c:11: member `i' is a protected member of class `foo'
----------------------------------------

However, the following *is* correct:

----------------------------------------
class foo {
protected:
   int i;
};

class bar : public foo {

public:   
   f () {
      i = 10; // OK, since bar is a derived type
   }
};
----------------------------------------

If you look at the example I showed (from Stroustrup's article, so it
had *better* be correct ;-)), you'll see that 

----------------------------------------
X a;
a.prot
----------------------------------------

is clearly trying to get ahold of the protected member, in the same
illegal sense of my first example above.  After all, ``a is not a Y!''

Does that make any more sense?

Doug

beshers%carcvax.brc.uconn.edu@PARIS.ICS.UCI.EDU (George Beshers) (01/28/89)

So is 1.2.1 (!).  I see your point.  Actually, my belief is that you
might want both possibilities.  Consider a container object for a
class X, then one possibility is to put the links in a protected
portion and derive the container class from the class supported.

				George
				beshers@carcvax.brc.uconn.edu