Path: utzoo!attcan!uunet!ksr!reg
From: reg@ksr.UUCP (Rick Genter)
Newsgroups: comp.lang.c++
Subject: Re: are 'friend's really necessary ??
Message-ID: <626@ksr.UUCP>
Date: 20 Mar 90 14:31:27 GMT
References: <169@pollux.kulcs.uucp> <10589@alice.UUCP> <1082@targon.UUCP>
Organization: Kendall Square Research Corp.
Lines: 47

In article <1082@targon.UUCP> ruud@targon.UUCP (Ruud Harmsen) writes:
>In article <10589@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes:
>>In article <169@pollux.kulcs.uucp>, herman@kulcs.uucp (Herman Moons) writes:
>>
>>> I don't know whether this question appeared earlier on the net.
>>> Are there any *good* reasons for having the friend concept in C++ ?
>>
>>Sure.  One of the most common is when you're writing several
>>interrelated classes.
>>
>
>Only too true.  And isn't this also the fundamental weakness of the object
>oriented concept?  For in the real world, and so in any realistic
>information system describing a part of that real world, *nearly all*
>classes are interrelated to *nearly all* other classes.  Classes often only
>make sense just because of their relations to other classes.
>So if you have to use friends for that, everyone will be anybody's friend,
>and as a result of all this friendship, a *real* project in an OO-language
>tends to become just the same mess as it does in a traditional language,
>like C.
>
>(Note: I admit I don't have experience with OOT, but only more so
>with complicated applications).

As one who does have experience with OOT and with complicated applications,
I (unfortunately) have to agree with the gist of this assessment.

There are classes of applications where OOT is wonderful.  User interface is
one.  Discrete simulation is another.  But how about a globally-optimizing
incremental compiler?  Or an operating system?

Actually, operating systems have potential; there are lots of "independent"
objects that have well defined behaviors (e.g., processes, threads, files,
users :-), but then there is all the other "cruft."  Is a protocol an object?
If not, how does it fit in to an OO OS?

Note that these can be made to work, but at a significant performance penalty.
The penalty is not the penalty of a single virtual method invocation vs.
a single function call; I grant that that is (usually) insignficant.  But
often what happens is that a method will invoke several other methods, each of
which will invoke other methods, and so on and so on.  Suddenly that
insignificant overhead becomes quite significant.

It seems to me that a study needs to be performed not on how to make everything
OO, but on how to make composite designs work: i.e., how do I easily integrate
my OO UI with my procedural data-flow analysis.
					- reg