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: <85@cybaswan.UUCP> Date: 14 Sep 88 01:39:13 GMT Organization: University College of Swansea Lines: 109 I wrote this letter in reply to mail received from MARC SHAPIRO in reply to the query I posted in this newsgroup on the subject of friends. I'm posting this here to contribute to what has turned into an interesting discussion. * To: shapiro@fr.inria.sor * * Thank you very much for your reply. I do not agree with your arguments * and have tried to answer each of them. I hope I can loosen your convictions * somewhat! ------------------------- > 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. An interesting spec; what was your intended application for plex objects? > 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. Why? To me, all this says is that a plex needs to be able to create a chunk from the data supplied. > Chunk also has friend access to plex; this is > not strictly necessary (actually, it's a bit unclean) I agree on both counts. > but the code is > more readable because the operations on the list as a whole are partof > plex, As they should be. (An object should operate at the level of abstraction it is implementing, not at one above or below.) > whereas operations concerning a single chunk and its immediate > neighbours are in chunk. As they should be in a class-based system. (In an object-based system, in contrast, a chunk wouldn't be able to operate on any other chunk --- see one of the other ongoing discussions in comp.lang.c++) However, you don't say why this good partitioning of operations is only achievable by giving chunks friend access to plex, and I don't see such a need at all. > 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. Friend access is not necessary for efficiency; inline functions appro- priately chosen can do this for you with equal effectiveness. > 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. I consider this to be an ill-structured and dangerous approach. By all means let a chunk know which plex it's on if your application needs this, but threading itself onto a plex directly is dangerous as it bypasses the plex's control over its contents. The chunk should be asking the plex to perform such a service on its behalf. > The plex may modify a > chunk, in order to store a datum in it. Notice that you're not really modifying a chunk, but the contents of the cell where the old chunk used to be! This is a C approach to programming, not object-oriented C++! > 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. Using your own reasoning, the updates should also be done with inline members --- then you'll have only one place to look! > 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. Great, we should all be doing this since C++ is quite ameanable to treatment this way, particularily when objects are left alone and not poked directly from outside via friend access! Can you give me details of how you do this? ----------------------- That's it! If you disagree with any of my reasoning or can support your claim with further evidence, please write further. (For now, from 8 replies, only Bjarne Stroustrup has come up with something really requiring friends in C++, and that's got to do with coercion with operators and does NOT require inter-class friend access --- see article <8163@alice.UUCP>.) Regards, Rich -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~