home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / cplus / 1919 < prev    next >
Encoding:
Text File  |  1992-12-25  |  3.2 KB  |  69 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
  3. From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  4. Subject: Re: Pointer comparisons
  5. Message-ID: <9236102.3238@mulga.cs.mu.OZ.AU>
  6. Sender: news@cs.mu.OZ.AU
  7. Organization: Computer Science, University of Melbourne, Australia
  8. References: <1992Dec19.001851.22116@microsoft.com> <1992Dec22.174327.8903@lpi.liant.com>
  9. Date: Fri, 25 Dec 1992 15:16:59 GMT
  10. Lines: 57
  11.  
  12. pkt@lpi.liant.com (Scott Turner) writes:
  13.  
  14. >In article <1992Dec19.001851.22116@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
  15. >> On the contrary, for the test to not prove true would
  16. >> mean that the empty base class part has to be implemented by the compiler
  17. >> using gratuitous padding, and gratuitous padding is an anathema to
  18. >> traditional C/C++ implementation.  
  19. >
  20. >"Gratuitous" is your own judgment.  Some of us disagree.
  21. >Moreover, such padding is in the C++ tradition.  
  22.  
  23. One of the most important principles of C was that if you didn't use a
  24. feature, you shouldn't have to pay for it. This principle was carried
  25. through to C++. On the topic "Design Notes", Bjarne Stroustrup wrote
  26.     "Features that would incur run-time or memory overheads even when
  27.     not use were avoided" [C++PL, 2nd Ed. pg 3].
  28.  
  29. As a feature, padding empty base classes fits this description exactly.
  30. It has a very significant memory overhead, especially if there
  31. are multiple levels of derivation involved. Such padding could easily
  32. double (or worse!) the memory required for classes derived from
  33. abstract base classes.
  34.  
  35. Stroustrup goes on to say
  36.     "For example, ideas that would make it necessary to
  37.     store ``housekeeping information'' in every object
  38.     were rejected; if a user declares a structure consisting
  39.     of two 16-bit quantities, that structure will fit into
  40.     a 32-bit register" [Ibid.]
  41.  
  42. In the case of deriving from empty structures, it is absolutely TRIVIAL
  43. to insert padding yourself *IF* you really need the addresses to be different.
  44. If such padding were to be inserted by the compiler, then there would be
  45. NO WAY to turn this feature off in cases where you weren't using it.
  46.  
  47. To force implementations to insert such padding would go against one of
  48. the strongest guiding design principles for both C and C++.
  49.  
  50. As a final point, I believe that requiring padding when deriving from
  51. abstract base classes would strongly discourage their use, for efficiency
  52. reasons. This would be a very bad thing IMHO, because abstract base classes
  53. are a very important design tool, and if the design can't be represented
  54. directly in the programming language, then there is a significant cost
  55. in terms of productivity and maintainability.
  56.  
  57. The concise OED defines "gratuitous" as (amoung other things)
  58. "uncalled for, unwarranted". Given the above arguments, I would
  59. definitely describe inserting padding when deriving from empty
  60. classes as "unwarranted". Furthermore, if the programmer didn't
  61. ask for the padding and didn't want it, how could you say it was
  62. anything other than "uncalled for"?
  63.  
  64. -- 
  65. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  66. This .signature virus is a self-referential statement that is true - but 
  67. you will only be able to consistently believe it if you copy it to your own
  68. .signature file!
  69.