home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / cplus / 17989 < prev    next >
Encoding:
Text File  |  1992-12-15  |  3.0 KB  |  59 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!haven.umd.edu!wam.umd.edu!krc
  3. From: krc@wam.umd.edu (Kevin R. Coombes)
  4. Subject: Re: static members in derived classes
  5. Message-ID: <1992Dec15.150612.28264@wam.umd.edu>
  6. Sender: usenet@wam.umd.edu (USENET News system)
  7. Nntp-Posting-Host: rac1.wam.umd.edu
  8. Organization: University of Maryland, College Park
  9. References: <1992Dec11.145205.29761@wam.umd.edu> <1992Dec12.175244.17775@taumet.com> <1992Dec14.215407.21631@microsoft.com>
  10. Date: Tue, 15 Dec 1992 15:06:12 GMT
  11. Lines: 46
  12.  
  13. In article <1992Dec14.215407.21631@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
  14. >In article <1992Dec12.175244.17775@taumet.com> steve@taumet.com (Steve Clamage) writes:
  15. >|"Virtual static" has been proposed from time to time.  I don't know of
  16. >|any technical objections to it.  There are lots of good ideas for
  17. >|extensions to C++.  The question is always one of evaluating the costs
  18. >|and benefits of any proposed extension.
  19. >
  20. >The technical argument against it is that the same capability can be
  21. >implementing using virtual functions.  If the complaint is that virtual
  22. >functions are too slow to implement "virtual statics" then the counter-
  23. >reply is that compilers can use a fat table implementation [or other
  24. >implementation] instead of the common vtable implementation in order 
  25. >to reduce the cost of the virtual function call in these cases.
  26. >
  27. The article to which Steve Clamage replied (and I wrote) pointed out that
  28. the same capability could be achieved using virtual functions. I did not
  29. object to the speed; I objected to the fact that this approach was
  30. tedious and error-prone. In each derived class where I wanted to add
  31. a different "virtual static" member, I had to add a new static member
  32. and add the virtual functions to manipulate it. And besides, it looks
  33. ugly.
  34.  
  35. Is it really the case that the only objection is that it can already be 
  36. achieved using existing techniques?
  37.  
  38. >Going the opposite direction people who propose "virtual static" do so
  39. >on the basis of an assumed vtable implementation of virtual functions.
  40. >In which case including "virtual static" begins to dictate one implementation
  41. >over other potentially faster implementations, which is not a good thing
  42. >to do.  Language should specify language, not dictate implementation.
  43. >
  44.  
  45. I don't see how it follows that allowing "virtual static" data dictates
  46. a particular implementation. Certainly, language definitions should not
  47. restrict implementations unnecessarily. However, I think of "virtual
  48. static" data as completing the following picture: Member functions belong
  49. to the class; data members belong to individual objects. Things that
  50. belong to the class can be delegated to derived classes by calling them
  51. "virtual". Things that belong to individual objects don't need to be
  52. made virtual, because they can have their own values anywhere you need
  53. them. Static data members, on the other hand, are neither here nor there.
  54. They belong to the class, but you cannot vary them in derived classes.
  55.  
  56. Kevin Coombes <krc@math.umd.edu>
  57.  
  58.  
  59.