home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / cplus / 1971 < prev    next >
Encoding:
Text File  |  1993-01-05  |  1.5 KB  |  32 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!microsoft!hexnut!jimad
  3. From: jimad@microsoft.com (Jim Adcock)
  4. Subject: Re: pointer comparisons
  5. Message-ID: <1993Jan05.004950.12883@microsoft.com>
  6. Date: 05 Jan 93 00:49:50 GMT
  7. Organization: Microsoft Corporation
  8. References: <1993Jan2.211538.11320@lpi.liant.com>
  9. Distribution: usa
  10. Lines: 20
  11.  
  12. |In article <9300300.29900@mulga.cs.mu.OZ.AU> (Fergus James HENDERSON) 
  13. |writes:
  14. |>   "The _sizeof_ operator yields the size, in bytes, of its operand".
  15. |> I think that it would be a very brave compiler-writer whose compiler
  16. |> made it unreliable to write() an object and read() it in again, because
  17. |>   read(fd, &object, sizeof object);
  18. |> randomly trashes the bytes past the end of the object.
  19.  
  20. Yet in the example I posted of a vacuous baseclass and a first member
  21. of the base type, no such problem exists.  Sizeof == 1.  Bytes required
  22. within the structure by the baseclass "subobject" == 0.  
  23. And read(fd, &object, sizeof object) *does not* randomly trash the bytes
  24. past the end of the object.  Further, this implementation is consistent
  25. with the ANSI-C base document *mandate* that implementations do not
  26. introduce padding into a structure before the first member. 
  27. ANSI-C mandates that the address of the first member be the same as the 
  28. address of the structure.  Unless there is overriding reason in the ARM
  29. why this cannot be the case, then the ANSI-C base document ought to be
  30. respected.  My claim is that there is no such overriding ARM requirement.
  31.  
  32.