[comp.lang.c++] Friend specifier considered harmful

eeartym@cybaswan.UUCP (Dr R.Artym eleceng ) (08/26/88)

	This is not the flame-attracting exercise that the subject line
would seem to indicate ---  what I'm really after are the group's opinions
on the basic notion that direct access to any data element of another class
is *ALWAYS* a bad idea, and should be avoided at all cost.
	So far I haven't come across any situation where friends are really
necessary ---  most cases seem to derive from a lack of object-oriented
structuring, or the requirements can be met with inline functions.
	My own concerns lie with the impact of this loosening of the class
system on the software engineering aspects of programming.  In large systems,
small transgressions allow in the bugs.
	Do YOU have a c++ program that couldn't have been written without
the friend specifier?
			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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

newsuser@LTH.Se (LTH network news server) (09/02/88)

In article <61@cybaswan.UUCP> eeartym@cybaswan.UUCP (Dr R.Artym eleceng ) writes:
>	My own concerns lie with the impact of this loosening of the class
>system on the software engineering aspects of programming.  In large systems,
>small transgressions allow in the bugs.

I regard "friend" functions as a way of bending the rules a little, in
order to avoid bigger trouble -- rather like a white lie.  While this
may not be as clean as one would like, it is defendable if you stress
practical software engineering.  I have seen many Modula-2 and Ada
programs where the writer has been "forced" to use very large modules
because of too strict encapsulation.

>	Do YOU have a c++ program that couldn't have been written without
>the friend specifier?

No, but I think my programs have improved by the use of a few friend
functions and classes.

General comment: I think this raises the issue that class design is a
demanding task, especially if other people are going to use the
classes in another conext.  Should we start a discussion of GOOD
design of classes?

Dag Bruck
--
-- 
Department of Automatic Control		Internet:  dag@control.lth.se
Lund Institute of Technology		UUCP:   ...!enea!control.lth.se!dag
P. O. Box 118
S-221 00 Lund, SWEDEN			Phone:	+46 46-108779

baud@gt-eedsp.UUCP (Kurt Baudendistel) (09/02/88)

In article <61@cybaswan.UUCP> eeartym@cybaswan.UUCP (Dr R.Artym eleceng ) 
writes:

>	So far I haven't come across any situation where friends are really
>necessary ---  most cases seem to derive from a lack of object-oriented
>structuring, or the requirements can be met with inline functions.

the trick is that this may be true in the general case, but as with most
things in c++, decisions are colored by the magic concept of *efficiency*.
it is often in the programmers' best interests to use friends for this
reason when creating related classes.  a good example is vector and
matrix classes.

-- 
Kurt Baudendistel [GRA McClellan]
Georgia Tech, School of Electrical Engineering, Atlanta, GA  30332
USENET: ...!{allegra,hplabs,ihnp4,ulysses}!gatech!gt-eedsp!$me
INTERNET: $me@gteedsp.gatech.edu

ark@alice.UUCP (Andrew Koenig) (09/02/88)

In article <61@cybaswan.UUCP>, eeartym@cybaswan.UUCP (Dr R.Artym eleceng ) writes:

> 	Do YOU have a c++ program that couldn't have been written without
> the friend specifier?

Obviously not -- I can write a universal Turing machine
simulator without the friend specifier.  But the real question is:
Are there problems for which friends are the ``best'' solution?

My answer is YES.  Friends are useful any time you want to have
several interrelated classes that can't be naturally described
by inheritance.

For example, a linear algebra package might have Vector and Matrix
classes.  Although some people might claim that a vector is
just a 1xN matrix, others might prefer an Nx1 matrix, and
therefore I suggest that vectors and matrices are really
different beasts and neither is a species of the other.

Now, how do you write a function to multiply a Matrix by a
Vector?  It apparently needs to know about the internal
representations of both classes.  Moreover, symmetry suggests
that it should be a member of both or neither -- which
perforce means neither.  Friends are the only way to make
this possible.

If you are tempted to respond that this just shows that
matrices and vectors should either be the same class
or one should inherit from the other, my response is that
my argument still holds for any two classes that need
to be linked by some means other than inheritance --
you won't convince me that friends are unnecessary until
you have convinced me that no such classes can ever exist.
-- 
				--Andrew Koenig
				  ark@europa.att.com

chip@ateng.uucp (Chip Salzenberg) (09/03/88)

According to eeartym@cybaswan.UUCP (Dr R.Artym eleceng ):
>	Do YOU have a c++ program that couldn't have been written without
>the friend specifier?

Well, there is almost no language feature which is truly indispensible, but
I used "friend" once where it proved very useful: an implementation of a
hash table.

The HashTable class contains an array of pointers to HashNode.  Each
HashNode contains a pointer to the next HashNode.  I made HashTable a friend
of HashNode.  This allowed easy access to the HashNode "next" pointer but
_only_ for HashTable member functions.
-- 
Chip Salzenberg                <chip@ateng.uu.net> or <uunet!ateng!chip>
A T Engineering                My employer may or may not agree with me.
	  The urgent leaves no time for the important.

bs@alice.UUCP (Bjarne Stroustrup) (09/03/88)

A friend function can be used to express that coercions is acceptable
for the left hand operand of an operator. Such coercions are not aceptable
for the left hand operand of an operator defined as a member function:

	class Int {
		// ...
	public:
		Int(int);	// e.g. Int(27)
		Int(string);	// e.g. Int("123456789123456789")

		friend Int operator+(Int,Int);
		friend Int operator*(Int,Int);
		// ...
		Int operator=(Int);
		// ...
	};

	main()
	{
		Int a = 1;

		a+1;		// operator+(a,Int(1))
		1+a;		// operator+(Int(1),a)
		a = 1;		// a.operator+(Int(1))
		1 = a;		// illegal
	}

This could be expressed without the use of friend functions (but not
in C++, since you cannot specify a member function for a built-in type
so int::operator(Int) cannot be defined). It could, however, also be
expressed without the use of member functions.

It can also be expressed without the use of coercions, but that leads
to an explosion of operator functions.

seeger@beach.cis.ufl.edu (Charles Seeger) (09/06/88)

In article <1988Sep2.094800.16353@LTH.Se> dag@Control.LTH.Se (Dag Bruck) writes:
>  Should we start a discussion of GOOD
>design of classes?
>
>Dag Bruck

I think that is a great idea.  I could learn a lot.

Chuck

fox@garfield (David Fox) (09/07/88)

In article <1988Sep2.174327.6439@ateng.uucp> chip@ateng.UUCP (Chip Salzenberg) writes:
>I used "friend" once where it proved very useful: an implementation of a
>hash table.
>
>The HashTable class contains an array of pointers to HashNode.  Each
>HashNode contains a pointer to the next HashNode.  I made HashTable a friend
>of HashNode.  This allowed easy access to the HashNode "next" pointer but
>_only_ for HashTable member functions.

Yes, this is an example of `friend' creating *more* type security rather than
less.  The HashNode class need have *no* public members whatsoever, so that
the class itself effectively becomes a private `member' of the HashTable
class.

-David Fox

lpringle@bbn.com (Lewis Pringle) (09/08/88)

In article <8160@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes:
>
>For example, a linear algebra package might have Vector and Matrix
>classes.  Although some people might claim that a vector is
>just a 1xN matrix, others might prefer an Nx1 matrix, and
>therefore I suggest that vectors and matrices are really
>different beasts and neither is a species of the other.
>
>Now, how do you write a function to multiply a Matrix by a
>Vector?  It apparently needs to know about the internal
>representations of both classes.  Moreover, symmetry suggests
>that it should be a member of both or neither -- which
>perforce means neither.  Friends are the only way to make
>this possible.

I am not sure that your example well illustrates your point, since accessing
the size, and elements of both vectors and matrices would be public methods of
those classes.  I think thats really all you need to implement multiplication,
even if you are efficiency hacking (in which case inline functions as accessors
to the matrices would be a good choice).

I am not sure if I like the use of friends, but I can share a place where I
used them, and could not think of a better way.

I was implementing an object-oriented portable windowing system, and I defined
high level window object (class).  It had pointers to implementation specific
structures (e.g. the OS Window pointer) which needed to be referenced by
another class (the Controls).  I could have made a public accessor for this
machine-dependent information, but I wanted the public interface to be entirely
portable, and the use of friends was the only way I could find to acheive that.

It seems to me that the trouble is that C++ provides a restrictive form of
data hiding (not that I know of a better way!): its too "all or nothing".
The use of friends is not exacly what you want.  Perhaps if in
specifying a friend,you didn't give blanket access to the given class,
but instead to just an explicitly stated set of members?

					Lewis.
"OS/2: half an operating system for half a computer."

In Real Life:		Lewis Gordon Pringle Jr.
Electronic Mail:	lpringle@labs-n.bbn.com
Phone:			(617) 873-4433

jss@hector.UUCP (Jerry Schwarz) (09/09/88)

My perspective on "friends" is that they are another C++ mechanism
for creating a public interface to a class.  As such, the
considerations that go into deciding whether to declare a friend are
essentially the same as those that go into deciding whether to
declare a public member.

There are two import distinctions between member functions and friend
functions.

        1.  Syntactic.  Friends are invoked using ordinary function
            notation rather member (. or ->) syntax.  Or in the case
            of friend operator, they may be invoked with the class
            object as the second operand.

        2.  A friend may be part of the interface of more than one
            class.

Both 1 and 2 may play a part in deciding to use a friend rather than
a member.

Jerry Schwarz
AT&T Bell Labs, Murray Hill

shopiro@alice.UUCP (Jonathan Shopiro) (09/09/88)

In article <29433@bbn.COM>, lpringle@bbn.com (Lewis Pringle) writes:
> ...
> It seems to me that the trouble is that C++ provides a restrictive form of
> data hiding (not that I know of a better way!): its too "all or nothing".
> The use of friends is not exacly what you want.  Perhaps if in
> specifying a friend,you didn't give blanket access to the given class,
> but instead to just an explicitly stated set of members?

Good idea!  In fact you can do exactly that, for example

class Foo {
	int	bar();
	int	baz();
};
class Foe {
	friend int Foo::bar();
	int	priv;
};

Then Foo:bar() can access priv in any Foe object, but Foo::baz() cannot.

I should also say that there seems no limit to the gradations of data
hiding that a programmer might want, for example you might want one
private member to be accessible to one external function and another
private member to be accessible only to a different external function.
However, the fundamental purpose of data hiding in C++ is to help the
programmer avoid bugs and it has no impact whatsoever on correct
programs.  Therefore, more elaborate data hiding schemes have two
strikes against themselves at the outset:  they make things more
complex by their very existence, but their justification must be that
they make things simpler.
-- 
		Jonathan Shopiro
		AT&T Bell Laboratories, Murray Hill, NJ  07974
		research!shopiro   (201) 582-4179