🚀 go-pugleaf

In article <46393@brunix.UUCP>, sdm@cs.brown.edu (Scott Meyers) writes:
|>Proposed:
|>
|>  That it be possible to declare member functions outside of class
|>  declarations exclusively for the purpose of later friend declarations.
|>
|>Example:
|>
|>  class Example;                      // currently legal
|>  void Example::f(int);               // currently illegal, but would be ok
|>
|>  class Sample {
|>    friend void Example::f(int);      // currently legal, provided class
|>                                      // Example has been defined
|> <stuff deleted here>
|>  };

Why should even this be necessary?  The friend declaration contains all
of the information necessary to deduce the declarations of Example and
Example::f(int), so why not omit these declarations too?

Perhaps I'm missing something here, but I don't see why it should be illegal
to declare a member function of a class not yet defined to be a friend.
You can declare a non-member function to be a friend whether that
function has been declared or not; likewise with an entire class.  Why the
special restriction for member functions?

Here's a particular case that's caused me trouble.   Say I have two
classes, low_level_object (LLO) and high_level_object (HLO).  HLO's are
really big things, including arrays of several different kinds of LLO's.
Since HLO's are built up out of LLO's and manipulate them extensively,
it makes sense to declare the LLO's first, right?  In the later stages
of development, however, there may be a significant optimization possible
by permitting one or two HLO member functions direct access to LLO data.
I would like to simply declare those one or two functions friends of the
LLO class, but instead I have to declare the whole HLO class to be a friend
of the LLO class and throw data hiding out the window.  Note that this is
the logical direction for friendship to go; no LLO function will ever
need access to HLO data or functions, but HLO's manipulate LLO's all the
time.

Yes, I know I could order things differently.  Declare LLO to be a class
but don't define it, then define HLO, then define LLO and its inline
member functions, then finally define HLO's member functions including the
inline ones.  Besides being brain damaged, this approach prevents me from
defining HLO inline functions that call LLO functions in the HLO class
definition.  The code is therefore bulkier, harder to read and harder to
maintain.  Privacy has become counterproductive when it makes it harder
to write well structured code.

In addition, no such kludge will permit you to define two classes, each
of which has a member function of the other as friend.  The best you can
do is declare one whole class to be a friend of the other.

Opinion:  I think data hiding is a Good Thing.  Occasionally, however,
you have to make exceptions to it---hence the friend mechanism.  This
mechanism should be as narrow and selective as possible, or data
hiding will be severely compromised.

OK, I'm done.  Now everbody all at once tell me why this is stupid and
couldn't possibly work.   :-)

Louis Howell

#include <std.disclaimer>