Path: utzoo!utgpu!watmath!watmsg!gjditchfield
From: gjditchfield@watmsg.waterloo.edu (Glen Ditchfield)
Newsgroups: comp.lang.c++
Subject: Re: protected friend classes?
Message-ID: <23920@watmath.waterloo.edu>
Date: 27 Feb 89 22:25:01 GMT
References: <99@riunite.ACA.MCC.COM>
Sender: daemon@watmath.waterloo.edu
Reply-To: gjditchfield@watmsg.waterloo.edu (Glen Ditchfield)
Organization: U. of Waterloo, Ontario
Lines: 44

In article <99@riunite.ACA.MCC.COM> rfg@riunite.UUCP (Ron Guilmette) writes:
>It seems that when I am building fancy linked data structures like queues,
>etc.  that I really need to use two classes; one to represent the "whole"
>thing (e.g. tree, list, etc.) and another to represent the "things" which
>are the nodes in the linked structure.  A simple example is
[class plain_item;			to hold the data,
 class stackable_item : plain_item;	to add the link fields, and
 class stack;				which stacks plain_items.
    stackable_item declares stack to be a friend, to allow access to the
 link field.  But this gives stack _too_ much access to stackable_item and
 plain_item. ]

   When I do this, I derive plain_item from stack_item, so the visibility
problem isn't so severe.
   The next problem occurs when I try to derive a class from stack;
friendship isn't inherited, so the new class can't manipulate links.  A
protected function in stack is needed.  I don't know whether this is a big
problem, or if inheriting friendship would cause even bigger problems.

>[Suggests that the visibility granted to a friend should depend on
> whether the friend declaration appears in a private, protected or public
> section.]
>Oh yes.  One other point.  If the current language rules limited the
>visibility of declared entities to their containing scopes, then I
>would never have had this problem in the first place.  I could have
>"nested" the declaration of the stackable_item class within the
>stack class, and just made the methods for the stackable_item class
>public.  Unfortunately, such nested declarations within classes "leak"
>out.

   I'd rather see proper nested classes (static and non-static) added to
the language than have "friend" change.  A "friend" change would probably
break much existing code, but nested classes probably wouldn't.  Given the
recent addition of static member functions, static member classes seems
like an obvious idea.  I think every argument in favor of static member
functions applies equally to static member classes.
   For a taste of how nested classes can be used, look up "Block Structure
in Object Oriented Languages" in SIGPLAN Notices v21 #10 (oct '86) or "The
BETA Programming Language" in "Research Directions in Object-Oriented
Programming", Shriver & Wegner, eds.  Warning:  BETA is _different_.

    Glen Ditchfield  gjditchfield@violet.uwaterloo.ca  Office: DC 2517
Dept. of Computer Science, U of Waterloo, Waterloo, Ontario, Canada, N2L 3G1
	"... and the rest, we will spend foolishly!" -- _Svengali_