home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / cplus / 1926 < prev    next >
Encoding:
Text File  |  1992-12-27  |  2.1 KB  |  49 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!lpi!pkt
  3. From: pkt@lpi.liant.com (Scott Turner)
  4. Subject: Re: pointer comparisons
  5. Message-ID: <1992Dec27.050118.1628@lpi.liant.com>
  6. Organization: Liant Software Corporation
  7. Date: Sun, 27 Dec 1992 05:01:18 GMT
  8. Lines: 39
  9.  
  10. In article <9236102.3238@mulga.cs.mu.OZ.AU> (Fergus James HENDERSON) writes:
  11. > One of the most important principles of C was that if you didn't use a
  12. > feature, you shouldn't have to pay for it. This principle was carried
  13. > through to C++. On the topic "Design Notes", Bjarne Stroustrup wrote
  14. >     "Features that would incur run-time or memory overheads even when
  15. >     not use were avoided" [C++PL, 2nd Ed. pg 3].
  16. > 
  17. > As a feature, padding empty base classes fits this description exactly.
  18.  
  19. "Padding empty base classes" is not the feature -- it's the
  20. simplest implementation.  The desired feature is:
  21.     Two pointers to the same type, which point to distinct objects
  22.     of that type, compare not equal.
  23.  
  24. > It has a very significant memory overhead, especially if there
  25. > are multiple levels of derivation involved. 
  26.  
  27. A smart implemetation would typically have no overhead.  The most practical
  28. example which has come up is Jamshid Afshar's, which incurs no overhead
  29. even with existing implementations.  The example which requires padding
  30. (originally Johan Bengtsson's) is contrived.
  31.  
  32. > In the case of deriving from empty structures, it is absolutely TRIVIAL
  33. > to insert padding yourself *IF* you really need the addresses to be different.
  34.  
  35. This is getting away from my point, but how do you know a compiler will 
  36. provide storage space for unused padding within a struct/class?
  37.  
  38. > Furthermore, if the programmer didn't
  39. > ask for the padding and didn't want it, how could you say it was
  40. > anything other than "uncalled for"?
  41.  
  42. There's a good chance the programmer needs data or object code compatibility 
  43. with other code.  The other code may use the above-described feature.
  44. --
  45. Prescott K. Turner, Jr.
  46. Liant Software Corp. (developers of LPI languages)
  47. 959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
  48. UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com
  49.