home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / cplus / 16002 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  3.2 KB
  1. Xref: sparky comp.lang.c++:16002 comp.std.c++:1524
  2. Newsgroups: comp.lang.c++,comp.std.c++
  3. Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  4. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  5. Subject: Re: PROPOSAL: Hidden private parts of classes
  6. Message-ID: <1992Nov10.011938.28327@ucc.su.OZ.AU>
  7. Sender: news@ucc.su.OZ.AU
  8. Nntp-Posting-Host: extro.ucc.su.oz.au
  9. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  10. References: <1992Oct30.113234.15010@daimi.aau.dk> <1992Nov7.154137.21910@ucc.su.OZ.AU> <1992Nov9.032225.10320@taumet.com>
  11. Date: Tue, 10 Nov 1992 01:19:38 GMT
  12. Lines: 61
  13.  
  14. In article <1992Nov9.032225.10320@taumet.com> steve@taumet.com (Steve Clamage) writes:
  15. >maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  16. >
  17. >>    Having hidden data variables causes the compiler some minor
  18. >>inconvenience, not knowing the length. However private non-virtual
  19. >>member functions cause no problems (if they were allowed). These are
  20. >>IMHO needed so as to be able to write small helper members in
  21. >>the implementation, I've suggested this be allowed, a suitable 
  22. >>syntax does not suggest itself though.
  23. >
  24. >If you mean private non-virtual member functions which don't appear in
  25. >the class definition, it would cause another language change.
  26.  
  27.     Yes, I propose ad additional keyword 'hidden' as well.
  28. Hidden is like private, but is truly invisible not just inaccessible.
  29. Static and non-virtual hidden functions can be defined without
  30. declaring them in the clas interface, data must be declared in the
  31. interface (but is still not visible outside the class).
  32.  
  33. >Overloading is resolved before accessibility is checked.  Suppose we have:
  34. >
  35. >    class X {
  36. >        foo(double);    // private
  37. >    public:
  38. >        foo(int);
  39. >    };
  40. >    void bar()
  41. >    {
  42. >        X x;
  43. >        x.foo(2.0);        // which foo() ?
  44. >    }
  45. >
  46. >This code is in error, since the best match is a private function.  The
  47. >semantics would change if "foo(double)" did not have to appear in the
  48. >publicly-used class definition; "foo(int)" would be called.  Overloading
  49. >is resolved first precisely to avoid quiet semantic changes based only
  50. >on access rights.
  51.  
  52.     I know. I do not propose to change 'private', but only add 'hidden'.
  53. It would even be possible to have two different definitions of hidden
  54. functions in different modules (thought perhaps not desirable).
  55. Similar calls in private functions and public ones might resolve
  56. differently, which is not nice, but neither the deriver nor the public
  57. will need to cope with this, only the programmer of the class
  58. implementation. 
  59.  
  60.     In anycase there are several situations where one might
  61. desire something like hidden functions. Often I am implementing
  62. a class and need a helper member, I do not want this arbitrary
  63. part of the implementation to be visible or cause recompilation
  64. of client modules. Such helpers are particularly needed in C++
  65. which does not allow nested functions. It is possible to write
  66. non-member static helper functions, but not members.
  67.  
  68.     Perhaps there is a better way to do it.
  69.  
  70. -- 
  71. ;----------------------------------------------------------------------
  72.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  73.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  74. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  75.