Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!seismo!munnari!otc!mikem
From: mikem@otc.UUCP
Newsgroups: comp.lang.c++
Subject: Re: proposed info-hiding mechanism
Message-ID: <96@otc.OZ>
Date: Wed, 11-Mar-87 18:15:51 EST
Article-I.D.: otc.96
Posted: Wed Mar 11 18:15:51 1987
Date-Received: Fri, 13-Mar-87 07:23:08 EST
References: <408@inria.UUCP>
Organization: O.T.C. Systems Development, Australia
Lines: 57

In article <408@inria.UUCP>, shapiro@inria.UUCP (Marc Shapiro) writes:
> 
> [ ... deleted ... ]
> 
>   class sosObject {
> 	long size;
> 	int fd;
>    protected:
> 	write_me_to_disk () {return ::write(fd, (void*)this, size);}
> 	}
> 
>   class A: public sosObject {
> 	...
> 	}
> 
>   class B: public sosObject {
> 	foo (A *a) { a -> write_me_to_disk(); }		// legal !
> 	}
> 
> The above example shows that even though B is not derived from A, B has
> access to A's 'protected' members.
> 

Surely this is simply just a BUG, and is not really legal at all. My
understanding was that things derived from A would be able to access
A's write_me_to_disk(), but certainly this would be prohibited for
siblings of A.

There is at least one other bug in release 1.1 which I'm aware of that
relates to this sort of thing:

    class Base {
	protected:
	    prot_member();
    };

    class Derived : public Base {
	 // Derived can use prot_member()

	 friend somefunc(Derived *d) { d->prot_member(); }

			      // somefunc should be able to use prot_member()
			      // for an object of type Derived. In release
			      // 1.1 this gives an error message complaining
			      // that prot_member is protected.
    };


I suspect that release 1.2 may address this, but since we're currently
awaiting delivery, I can't say for sure. I might post a follow-up when
we have 1.2 going.

			Mike Mowbray
			Systems Development
			Overseas Telecommunications Commission (Australia)

UUCP:   {seismo,mcvax}!otc.oz!mikem              ACSnet: mikem@otc.oz