🚀 go-pugleaf

I keep running into the problem where I have dual class heirarchies
and need to specify friend in one for the other.  However, since
friend is not inherited every time a class is subclassed it is necessary
to specify yet another friend.  For example, suppose I have...

   struct BinaryNode {
      friend BinaryTree;
      friend AvlTree;
      ...};

   struct AvlNode {
      friend AvlTree;
      ...};

   struct BinaryTree {...};
   struct AvlTree : BinaryTree {...};

If I add...

   struct RankedAvlNode : AvlNode {
      friend RankedAvlTree;
      ...};

   struct RankedAvlTree : AvlTree {...};

then it is necessary to add new friend statements to BinaryNode
and to AvlNode.

The problem is that friend is designed to support those situations
where classes are tightly coupled for some reason, such as a
collection and its iterator.  However, with the greater use of
frameworks and design patterns, tightly coupled dual class
heirarchies are becoming more and more common.  Even in the
collection and iterator example, it is more likely to be parallel
class heirarchies rather than simply two classes.

All the usual reasons for protected/private data members and
functions apply as well as the reasons for using friend.  While
I certainly don't think that friend should be used often, its use
is essential for good design in many situations -- especially when
building frameworks.

Does the draft standard address this issue, and if not should a
variant of friend be defined.  Say...

   class BinaryNode {
      friends BinaryTree;
      ...};

would solve the problem quite nicely.  This is a major problem
in keeping a clean design for larger systems.


Michael Lee Finney



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]