Path: utzoo!attcan!uunet!mcvax!ukc!reading!cf-cm!cybaswan!eeartym From: eeartym@cybaswan.UUCP (Dr R.Artym eleceng ) Newsgroups: comp.lang.c++ Subject: Re: Friend specifier considered harmful Message-ID: <84@cybaswan.UUCP> Date: 14 Sep 88 01:35:03 GMT Organization: University College of Swansea Lines: 63 Letter 1 --- I'm posting this on behalf of MARC SHAPIRO: -------------------------------------------------------- * From shapiro@fr.inria.sor Thu Sep 8 19:08:09 1988 * Organization: INRIA, BP 105, 78153 Le Chesnay Cedex, France * telephone +33(1)39-63-55-11, telex 697033 F, telecopy +33(1)39-63-53-30 * To: eeartym@uk.ac.swan.pyr * Subject: Re: Friend specifier considered harmful * Newsgroups: comp.lang.c++ In article <61@cybaswan.UUCP> you write: > Do YOU have a c++ program that couldn't have been written without >the friend specifier? Yes. I have written a generic ``plex'' or ``flexible array'' (i.e. an array which can grow or shrink at either end). The plex is a linked list of ``chunks''. An iterator object allows to traverse the plex upwards, or downwards, or any old way. You may declare any number of independent iterators for a single plex. These 3 classes are all friends of each other. Since the actual data of a plex is the contents of the chunks, the plex better have friend access to chunk. Chunk also has friend access to plex; this is not strictly necessary (actually, it's a bit unclean) but the code is more readable because the operations on the list as a whole are partof plex, whereas operations concerning a single chunk and its immediate neighbours are in chunk. Finally, iterator has access to plex for efficiency. The whole idea of an iterator is to abstract from the many individual operations needed to access elements in succession; might as well do that efficiently. Note however that iterator never changes the plex (the ``plex'' field of iterator is declared ``const''). A chunk may modify the plex, in order to thread itself onto the linked list. The plex may modify a chunk, in order to store a datum in it. All read access to fields is mediated by inline functions, as well as all the ``high-level'' write operations (like storing a datum). Only those write operations which update the specific representation set the corresponding fields directly. This is good, so that if I change the representation I know exactly where to change the code. Finally, I make a great use of assertions and invariants to make sure at all times that my assumptions are correct and the structure is not broken. Marc Shapiro INRIA, B.P. 105, 78153 Le Chesnay Cedex, France. Tel.: +33 (1) 39-63-53-25 e-mail: shapiro@inria.inria.fr or: ...!mcvax!inria!shapiro -------------------------------------------------------- -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Keywords: Parallel, Applicative, and Object-Oriented Languages and Systems --------------------------------------------------------------------------- Dr. Richard Artym, + UUCP : ..!ukc!pyr.swan.ac.uk!eeartym Electrical Engineering Dept., + JANET : eeartym@uk.ac.swan.pyr University of Wales, + Phone : [(0792) or (+44 792)] 295536 Swansea, SA2 8PP, + Fax : [(0792) or (+44 792)] 295532 U.K. + Telex : 48358 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~