home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 13237 < prev    next >
Encoding:
Text File  |  1992-09-02  |  1.3 KB  |  39 lines
  1. Path: sparky!uunet!usc!cs.utexas.edu!ut-emx!jamshid
  2. From: jamshid@ut-emx.uucp (Jamshid Afshar)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Inherited nested classes?
  5. Summary: just make them friends
  6. Message-ID: <78983@ut-emx.uucp>
  7. Date: 2 Sep 92 23:32:13 GMT
  8. References: <1992Aug29.160423.16617@genghis.borland.com> <4902@holden.lulea.trab.se>
  9. Reply-To: jamshid@emx.utexas.edu
  10. Organization: The University of Texas at Austin; Austin, Texas
  11. Lines: 26
  12.  
  13. In article <4902@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
  14. >Can struct B use its own name?  After all it is a private name to which
  15. >it has no access (access control applies uniformly to all names,
  16. >including nested types)...
  17.  
  18. C'mon, let's save the pedantry for the ANSI C++ draft :-).
  19.  
  20. >Are private nested types useful at all, given the current language definition?
  21.  
  22. Yes -- in those situations where the inner class needs to "know" the
  23. internals of its enclosing class, make it a friend.
  24.  
  25.     class A {
  26.        enum E { zero, one, two, three };  // a private type of A
  27.        class PrivateBuddy; friend PrivateBuddy;
  28.        class PrivateBuddy {
  29.           E e;  // E only accessible to A and friends
  30.           //...
  31.        };
  32.     public:
  33.        //...
  34.     };
  35.     // A::PrivateBuddy and A::E only accessible by A
  36.  
  37. Jamshid Afshar
  38. jamshid@emx.utexas.edu
  39.