home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16398 < prev    next >
Encoding:
Text File  |  1992-11-17  |  2.3 KB  |  71 lines
  1. Newsgroups: comp.lang.c++
  2. From: nikki@trmphrst.demon.co.uk (Nikki Locke)
  3. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!sun-barr!cs.utexas.edu!convex!news.utdallas.edu!corpgate!bnrgate!bnr.co.uk!pipex!demon!trmphrst.demon.co.uk!nikki
  4. Subject: Member function renaming proposal from the ARM
  5. Reply-To: nikki@trmphrst.demon.co.uk
  6. Distribution: world
  7. X-Mailer: cppnews $Revision: 1.20 $
  8. Organization: Trumphurst Ltd.
  9. Lines: 57
  10. Date: Mon, 16 Nov 1992 13:31:40 +0000
  11. Message-ID: <721945900snx@trmphrst.demon.co.uk>
  12. Sender: usenet@gate.demon.co.uk
  13.  
  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. Let us assume two base classes with name clashes ...
  19.  
  20. class Lottery {
  21.     // ...
  22.     virtual int draw();
  23.     };
  24.  
  25. class GraphicalObject {
  26.     // ...
  27.     virtual void draw();
  28.     };
  29.  
  30. // The suggested extension would allow ...
  31. class LotterySimulation : public Lottery, public GraphicalObject {
  32.     // ...
  33.     virtual int l_draw() = Lottery::draw;
  34.     virtual void draw() = GraphicalObject::draw;
  35.     };
  36.  
  37. It is stated in the ARM that such a language extension is not _necessary_,
  38. and is only worthwhile if the need to resolve such name clashes proves 
  39. common. It strikes me that the workround suggested in the ARM is going to 
  40. cause some loss of efficiency on most compilers around today.
  41.  
  42. I see another use for this extension (see ARM also 13.1 pp310-312) ...
  43.  
  44. class Base {
  45. public:
  46.     // ...
  47.     virtual void set(int i);
  48.     virtual void set(double d);
  49.     virtual void set(char *s);
  50.     };
  51.  
  52. class Derived {
  53. public:
  54.     // ...
  55.     void set(int) = Base::set(int);
  56.     void set(double) = Base::set(double);
  57.     virtual void set(char *s);
  58.     };
  59.  
  60. This will prevent set(int) and set(double) being hidden by set(char *), 
  61. without any loss of efficiency in the calling mechanism.
  62.  
  63. Now I realise that there is no chance of including this in the current 
  64. standard (lets concentrate on getting it finished), but is it a sensible 
  65. enhancement to the language for some future date ? Or is there an existing
  66. construct which will do the job without any run-time efficiency penalty ?
  67.  
  68. -- 
  69. Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
  70. trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
  71.