home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / cplus / 1138 < prev    next >
Encoding:
Text File  |  1992-09-09  |  2.8 KB  |  78 lines
  1. Path: sparky!uunet!pipex!unipalm!uknet!mcsun!sunic!hagbard!loglule!jbn
  2. From: jbn@lulea.trab.se (Johan Bengtsson)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Zero-length structures and pointer comparisons
  5. Message-ID: <4945@holden.lulea.trab.se>
  6. Date: 9 Sep 92 19:26:46 GMT
  7. References: <9225302.22791@mulga.cs.mu.OZ.AU>
  8. Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
  9. Lines: 66
  10. X-Newsreader: Tin 1.1 PL4
  11.  
  12. fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
  13. : 
  14. : Secondly, some comments about C++.
  15. : In ANSI C, pointer comparisons between pointers to unrelated objects (ie.
  16. : objects that are not both members of the same aggregate) cause undefined
  17. : behavior,
  18.  
  19. Small clarifications:
  20.  
  21. The ARM is explicit about the relational operators (<,>,<=,>=),
  22. and then goes on to say the equality operators are "exactly analogous".
  23. Anyway, comparison with pointers to members of the same aggregate are only
  24. defined if they belong to the same access zone (simplified).  Also,
  25. pointer comparison within the same array is supported.
  26.  
  27. :I believe. For example, the following program
  28. :     #include <assert.h>
  29. :     int main() {
  30. :         int x,y;
  31. :         assert(&x != &y);
  32. :     }
  33. : should cause undefined behavior. [Is this correct?]
  34.  
  35. I'd say yes.  On a segmented architecture (can you say 'PC'?)
  36. pointer comparison need not use the full 32 bits for pointer comparison,
  37. instead a 16 bit offset may be used (note that this limits arrays to 64 KB).
  38.  
  39. I wonder if the 'PC' segmented architecture will reappear in the
  40. first 64 bit processors (representing pointers as 32 bit offsets within
  41. up to 2^32 segments)?  Does anyone have any info on this?
  42.  
  43. Anyway, the current rules do seem to cause trouble for the common (?)
  44. idiom for operator =:
  45.  
  46. const T& operator = ( const T& t )
  47. {
  48.     if ( &t == this ) return;    // avoid self-assignment
  49.     // ...
  50. }
  51.  
  52. Is the above idiom broken?
  53. Should the current rules be changed (inflicting a small performance penalty
  54. on some machines)?
  55.  
  56. : Given that this is the case, it seems contradictory that repeated calls to
  57. : operator new(0) are required to return pointers to "distinct objects".
  58. : How could a conforming program possibly detect whether this requirement
  59. : was actually met? Surely the following program
  60. :     #include <assert.h>
  61. :     int main() {
  62. :         assert(operator new(0) != operator new(0));
  63. :     }
  64.  
  65. If sizeof(long) >= sizeof(void*), then you should be able to
  66. test like this:
  67.  
  68. assert( (long)p1 != (long)p2 );
  69.  
  70. since a pointer stored in an integer variable must keep all information
  71. needed to restore the pointer (if the integer type is large enough).
  72.  
  73. -- 
  74. --------------------------------------------------------------------------
  75. | Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
  76. | Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
  77. --------------------------------------------------------------------------
  78.