home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / cplus / 1941 < prev    next >
Encoding:
Text File  |  1992-12-31  |  2.3 KB  |  60 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!titan!lpi!pkt
  3. From: pkt@lpi.liant.com (Scott Turner)
  4. Subject: Re: pointer comparisons
  5. Message-ID: <1992Dec31.170223.21637@lpi.liant.com>
  6. Sender: pkt@lpi (Scott Turner)
  7. Organization: Liant Software Corporation
  8. References: <1992Dec27.050118.1628@lpi.liant.com> <1992Dec30.184614.5551@microsoft.com>
  9. Date: Thu, 31 Dec 1992 17:02:23 GMT
  10. Lines: 48
  11.  
  12. In article <1992Dec30.184614.5551@microsoft.com> (Jim Adcock) writes:
  13. > Can you define your terms for us?
  14.  
  15. > "distinct objects" means what?
  16. It means the objects are not identical.  
  17.  
  18. I was going to say that the standard for C++ needs to spell out what it
  19. means for object to be identical in a better way than just by
  20.      1. An object is a region of storage.
  21.      2. A definition or a new expression reserves the storage
  22.         needed by the object.
  23. These two rules leave things much more loose than necessary when objects
  24. require no storage.  But note that section 1.3 of the working paper 
  25. (The C++ Memory Model) says:
  26.  
  27.     The constructs in a C++ program create, refer to, access, and
  28.     manipulate objects in memory.  Each object (except bit-fields)
  29.     occupies one or more contiguous bytes.
  30.  
  31. I missed this a while back when enumerating the features of the ARM and
  32. working paper which supported
  33. > The desired feature is:
  34. >     Two pointers to the same type, which point to distinct objects
  35. >     of that type, compare not equal.
  36. This excerpt from 1.3 gives the general rule I was seeking, because
  37. objects can be distinguished by the storage reserved for them.
  38.  
  39. The excerpt may raise a few questions.
  40.  
  41.     How much freedom does it leave a compiler to optimize away
  42.     an object's bytes (by application of the "as if" rule, etc.)?
  43.     I think a good deal of freedom, because the working paper
  44.     doesn't define the results if a program attempts to refer to
  45.     or manipulate the bytes of an object.
  46.  
  47.     Does it govern base class subobjects?  As I understand it,
  48.     base class subobjects are objects, and hence are covered.
  49.  
  50.     Does it belong in the C++ standard?  I'd say yes, given that
  51.     compilers will for many practical purposes be able to 
  52.     optimize away unneeded bytes.
  53.  
  54. --
  55. Prescott K. Turner, Jr.
  56. Liant Software Corp. (developers of LPI languages)
  57. 959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
  58. UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com
  59.     
  60.