Re: Cstring, string ,and char[]
On Tue, 19 Jun 2007 15:10:19 -0400, Joseph M. Newcomer
<newcomer@flounder.com> wrote:
But requiring the declaration of a class to anticipate all future users of the class is
not the right way to build software. Requiring that a friend class means you have to go
back and edit the source of the class is equally bad. For example, derivation and
encapsulation (in the COM sense) do not require that you modify the existing source (or
int he case of COM, you encapsulate the binary). But a 'friend' class requires that you
modify the original source to make the class known, and that's not really a good idea.
Extensions should be completely transparent to the oiginal source.
But "friend" is not meant to be used by ordinary users. It's to be used
only by the implementer of the class. For example, comparison operators for
a class T are usually implemented as non-members so that the operands are
subject to the same conversions; this allows you to say both x == y and y
== x such that only one of x and y *has* to have the type T. (With
operator== a member function, x has to be a T.) Often, functions like this
need to be friends of T, because T doesn't provide any other public
comparison function. Now, if you're an ordinary user of T who wants to
write these operators and can't because T doesn't define any comparison
function or any other way to get to its innards, which causes you to want
to become T's friend, the design of T is just plain wrong. The "friend"
mechanism is not an extensibility mechanism; it's a design mechanism, and
anytime you want to make yourself "friend" to a class you didn't write,
either the class design is deficient, or you don't understand it well
enough to leverage what it does make available to you.
--
Doug Harrison
Visual C++ MVP