We're always interested in getting feedback. E-mail us if you like
this guide, if you think that important material is omitted, if you
encounter errors in the code examples or in the documentation, if you
find any typos, or generally just if you feel like e-mailing. Mail to
Frank Brokken
or use an
e-mail form.
Please state the concerned document version, found in
the title. If you're interested in a printable
PostScript copy, use the
form, or
better yet,
pick up your own copy by ftp
from ftp.icce.rug.nl/pub/http.
Let's return to friend
s once more. In section 4.5.2 the
possibility of declaring a function or class as a friend of a class was
discussed. At the end of that section, we mentioned
A
changes, all its
friends must be recompiled (and possibly modified) as well.
In our opinion, there are indeed very few reasons for using the friend
keyword. It violates the principle of data hiding, and makes the maintenance
of a class dependent on another class.
Nonetheless, it might be worth while to look at some examples in which the
friend
keyword can be used profitably. Having seen such examples,
the decision about whether or not to use friend
s might be based on a
somewhat more solid foundation than on a plain rule of thumb.
At the onset, we remark that in our programming projects we never found
any convincing reason to resort to friend
s. Having thus made our position
clear, let's consider a situation where it would be nice
for an existing class to have access to another class.
Such a situation might occur when we would like to give an old class access to a class developed later in history.
However, while developing the older class, it was not yet known that the newer class would be developed later in time. E.g., the older class is distributed in the runtime-library of a compiler, and the newer class is a class developed by us.
Consequently, no provisions were offered in the older class to access the information in the newer class.
Consider the following situation. Within the C++
I/O-library the
extraction >>
and insertion <<
operators
may be used to extract from and to insert into a stream.
These operators can be given data of several
types: int, double, char *
, etc.. Now assume that we develop a class
String
. Objects of the class String
can be
given a string, and String
objects can also produce other
String
objects.
While it is possible to use the insertion operator to write the string that is stored in the object to a stream, it is not possible to use the extraction operator, as illustrated by the following piece of code:
String
class is also a bit of a kludge: it isn't the String
object that is inerted into the stream, but rather a string produced by
one of its members.
Below we'll discuss a method to allow the insertion and extraction of
String
objects, based on the use of the friend
keyword.
String
objects into
streams, rather than derivatives of String
objects, like
char const *
's. If we would be able to write String
objects into
streams, we could be using code comparable to
Analogously, with the extraction operator, we would like to be able to write code comparable to the next example:
In this situation we would not have to rely on the availability of a
particular member (like char const *String::get()
), and we would be able to
fill a String
object directly via the extraction operator, rather than
via an intermediate variable of a type understood by the cin
stream.
Even more central to the concept of object oriented programming: we would be
able to ignore the functionality of the String
class in combination
with iostream
objects: our objective is, after all, to insert the
information in the String
object into the cout
stream, and not
to call a particular function to do so.
Once we're able to focus our attention on the object, rather than on its
member functions, the above piece of code remains valid, no matter what
internal organization the String
object has.
>>
, to be used as an extraction
operator with a String
object:
String
objects. Unfortunately, this implementation produces awkward code.
The extraction operator is
part of the String
class, so its left operand must be a
String
object.
As the left operand must be a String
object, we're now forced to
use weird-looking code like the following, which can only partially be
compiled. The numbered statements are annotated next.
s
is the left-hand operator, and cin
the right-hand, consequently, this statement represents
extraction from a cin
object into a String
object.
cin >> x
is executed,
producing an istream &
, which is then used as a right-hand operand
with the extraction
to s
.
istream
's overloaded operator >>
doesn't know how to extract
information into String
objects.
A solution is to overload the global >>
operator to accept a
left-operand of the istream &
type, and a right operand of the
String &
type, returning an istream &
. Its
prototype is, therefore:
istream &operator>>(istream &is, String &str);
To implement this function, the implementation given for the overloaded
extraction operator of the String
class can't simply be copied, since
the private datamember str
is accessed there. A small (and perfectly legal)
modification would be to access the String
's information via a
char const *String::get() const
member, but this would again generate
a dependency on the String::get()
function, which we would like to
prevent.
However, the need for overloadeding the extraction operator arose strictly in
the context of the String
class, and is in fact depending on the
existence of that class. In this situation the overloading of the operator
could be considered an extension to the String
class, rather than to
the iostream
class.
Next, since we consider the overloading of the >>
operator in the context
of the String
class an extension of the String
class, we feel safe
to allow that function access to the private members of a String
object,
instead of forcing the operator>>()
function to assign the data members
of the String
object through the String
's member functions.
Access to the private data members of the String
object is granted by
declaring the operator>>()
function to be a friend
of the String
class:
Note that nothing in the implementation of the operator>>()
function
suggests that it's a friend of the String
class. The compiler detects
this only from the String
interface, where the operator>>()
function
is declared as a friend.
operator>>()
function for the String
class, it's hopefully clear that there is only
very little reason to declare it as a friend of the class String
, assuming
that the proper memberfunctions of the class are available.
On the other hand, declaring the operator>>()
as a friend function isn't
that much of a problem, as the operator>>()
function can very well be
interpreted as a true member function of the class String
, although, due
to a syntactical peculiarity, it cannot be defined as such.
To illustrate the possibility of overloading the >>
operator for the
istream
and String
combination, we present here the version which does
not have to be declared as a friend
in the String
class interface.
This implementation assumes that the class String
has
an overloaded operator =
, accepting as r-value a char const *
:
friend
functions might purely be a matter of taste. As yet, we haven't come across a
situation where friend
functions are truly needed.
For example, a window application can define a class Window
to contain the information of a particular window, and a class Screen
shadowing the Window
objects for those windows that are actually
visible on the screen.
Assuming that the window-contents of a Window
or Screen
object is accessible though a char *win
pointer, of unsigned size
characters, an overloaded operator
!=
can be defined in one (or both) classes to compare the contents of
a Screen
and Window
object immediately. Objects of the two
classes may then be compared directly, as in the following code fragment:
It is likely that the overloaded operator !=
and other member
functions of w (like refresh()
) will benefit from direct access to
the data of a Screen
object. In this case the class Screen
may declare the class Window
as a friend class, thus allowing
Window
's member functions to access the private members of its objects.
A (partial) implementation of this situation is:
It is also possible to declare classes to be each other's friends, or to declare a global function to be a friend in multiple classes. While there may be situations where this is a useful thing to do, it is important to realize that these multiple friendships actually violate the principle of encapsulation.
In the example we've been giving earlier for single friend
functions,
the implementation of such functions
can be placed in the same directory as the actual member
function of the class declaring the function to be its friend. Such functions
can very well be considered part of the class implementation, being
somehat `excentric` member functions.
Those functions will normally be inspected automatically
when the implementation of the data of the class is changed.
However, when a class itself is declared as a
friend of another class, things become a little more complex. If the sources
of classes are kept and maintained in different directories, it is not clear
where the code of Window::operator!=()
should be stored, as this
function accesses private members of both the class Window
and
Screen
. Consequently caution should be exercized when these
situations arise.
In our opinion it's probably best to avoid friend classes, as they violate of the central principle of encapsulation.