home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / cplus / 18027 < prev    next >
Encoding:
Text File  |  1992-12-15  |  2.8 KB  |  68 lines
  1. Path: sparky!uunet!mcsun!sunic!hagbard!loglule!jbn
  2. From: jbn@lulea.trab.se (Johan Bengtsson)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: static members in derived classes
  5. Message-ID: <5387@holden.lulea.trab.se>
  6. Date: 15 Dec 92 20:03:54 GMT
  7. References: <1992Dec14.215407.21631@microsoft.com>
  8. Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
  9. Lines: 56
  10. X-Newsreader: TIN [version 1.1 + PL8]
  11.  
  12. Jim Adcock (jimad@microsoft.com) wrote:
  13. : In article <1992Dec12.175244.17775@taumet.com> steve@taumet.com (Steve Clamage) writes:
  14. : |"Virtual static" has been proposed from time to time.  I don't know of
  15. : |any technical objections to it.  There are lots of good ideas for
  16. : |extensions to C++.  The question is always one of evaluating the costs
  17. : |and benefits of any proposed extension.
  18.  
  19. : The technical argument against it is that the same capability can be
  20. : implementing using virtual functions.
  21.  
  22. Agreed.
  23.  
  24. : If the complaint is that virtual
  25. : functions are too slow to implement "virtual statics" then the counter-
  26. : reply is that compilers can use a fat table implementation [or other
  27. : implementation] instead of the common vtable implementation in order 
  28. : to reduce the cost of the virtual function call in these cases.
  29.  
  30. I'd say it would take a pretty smart compiler to recognize the
  31. "virtual static idiom", noticing that
  32.  
  33. virtual void f();
  34. static void static_f();
  35.  
  36. in fact is equivalent to the (forbidden) construct:
  37.  
  38. static virtual void f();
  39.  
  40. And of course, this doesn't work, since you have to use two different
  41. names, f() and static_f().
  42.  
  43. : Going the opposite direction people who propose "virtual static" do so
  44. : on the basis of an assumed vtable implementation of virtual functions.
  45. : In which case including "virtual static" begins to dictate one implementation
  46. : over other potentially faster implementations, which is not a good thing
  47. : to do.  Language should specify language, not dictate implementation.
  48.  
  49. I like "virtual static", and I do not need the vtbls to back me up.
  50. It is more a question of orthogonality and removal of an exception
  51. to language rules.
  52.  
  53. Even if it was true that "virtual static" must be implemented using vtbls,
  54. you would only pay for it when you use it.  "Virtual static" could
  55. in principle use a different scheme than other virtual functions.
  56.  
  57. Also, the equivalence between "static virtual void f()" and two separate
  58. methods, one static and one virtual, is a direct disproof of your claim
  59. that "static virtual" dictates a particular implementation (assuming
  60. you are not also claiming that ordinary virtuals _must_ be implemented
  61. using vtbls).
  62.  
  63. -- 
  64. --------------------------------------------------------------------------
  65. | Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
  66. | Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
  67. --------------------------------------------------------------------------
  68.