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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~