home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16395 < prev    next >
Encoding:
Text File  |  1992-11-17  |  2.1 KB  |  61 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!caen!hellgate.utah.edu!fcom.cc.utah.edu!swillden
  3. From: swillden@news.ccutah.edu (Shawn Willden)
  4. Subject: Re: Member function renaming proposal from the ARM
  5. Message-ID: <1992Nov17.031938.10774@fcom.cc.utah.edu>
  6. Sender: news@fcom.cc.utah.edu
  7. Organization: University of Utah Computer Center
  8. X-Newsreader: Tin 1.1 PL3
  9. References: <721945900snx@trmphrst.demon.co.uk>
  10. Date: Tue, 17 Nov 92 03:19:38 GMT
  11. Lines: 48
  12.  
  13. nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
  14. : I have a question about an extension to the language to allow programmers 
  15. : to specify inheriting and optionally renaming functions. The extension is 
  16. : proposed in the ARM 10.11c (pp 236-237). 
  17. : 
  18.  
  19. [ proposal and ARM's reason for dismissal deleted ]
  20.  
  21. : I see another use for this extension (see ARM also 13.1 pp310-312) ...
  22. : 
  23. : class Base {
  24. : public:
  25. :     // ...
  26. :     virtual void set(int i);
  27. :     virtual void set(double d);
  28. :     virtual void set(char *s);
  29. :     };
  30. : 
  31. : class Derived {
  32. : public:
  33. :     // ...
  34. :     void set(int) = Base::set(int);
  35. :     void set(double) = Base::set(double);
  36. :     virtual void set(char *s);
  37. :     };
  38. : 
  39. : This will prevent set(int) and set(double) being hidden by set(char *), 
  40. : without any loss of efficiency in the calling mechanism.
  41. : 
  42. : Now I realise that there is no chance of including this in the current 
  43. : standard (lets concentrate on getting it finished), but is it a sensible 
  44. : enhancement to the language for some future date ? Or is there an existing
  45. : construct which will do the job without any run-time efficiency penalty ?
  46.  
  47. The standard trick of defining Derived::set(int) and Derived::set(double)
  48. as inline forwarding functions should work without any run-time penalty
  49. if the compiler is smart.  All it has to do is recognize what is happening
  50. and put the addresses of the Base methods in the Derived vtable.  Given
  51. that this is such an easy optimization I don't think we need a language
  52. extension for it (and another bit of syntax to learn).
  53.  
  54. : -- 
  55. : Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
  56. : trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
  57.  
  58. --
  59. Shawn Willden
  60. swillden@icarus.weber.edu
  61.