home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / cplus / 1146 < prev    next >
Encoding:
Text File  |  1992-09-10  |  2.6 KB  |  72 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!mcsun!news.funet.fi!network.jyu.fi!sakkinen
  3. From: sakkinen@jyu.fi (Markku Sakkinen)
  4. Subject: Re: Zero-length structures and pointer comparisons
  5. Message-ID: <1992Sep10.094957.23588@jyu.fi>
  6. Organization: University of Jyvaskyla, Finland
  7. References: <9225302.22791@mulga.cs.mu.OZ.AU> <4945@holden.lulea.trab.se>
  8. Date: Thu, 10 Sep 1992 09:49:57 GMT
  9. Lines: 61
  10.  
  11. In article <4945@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
  12. >fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
  13. >:  [ ... ]
  14. >  [ ... ]
  15. >:I believe. For example, the following program
  16. >:     #include <assert.h>
  17. >:     int main() {
  18. >:         int x,y;
  19. >:         assert(&x != &y);
  20. >:     }
  21. >: should cause undefined behavior. [Is this correct?]
  22. >
  23. >I'd say yes.  On a segmented architecture (can you say 'PC'?)
  24. >pointer comparison need not use the full 32 bits for pointer comparison,
  25. >instead a 16 bit offset may be used (note that this limits arrays to 64 KB).
  26. >  [ ... ]
  27. >Anyway, the current rules do seem to cause trouble for the common (?)
  28. >idiom for operator =:
  29. >
  30. >const T& operator = ( const T& t )
  31. >{
  32. >    if ( &t == this ) return;    // avoid self-assignment
  33. >    // ...
  34. >}
  35. >
  36. >Is the above idiom broken?
  37. >Should the current rules be changed (inflicting a small performance penalty
  38. >on some machines)?
  39.  
  40. Oh dear, why have I not noted this _horrible_ defect in the language
  41. definition before?  Probably because it was too bad to be suspected.
  42. The above idiom is certainly common, and it is used in Stroustrup's
  43. own books.  The first example I could found now in "The C++ P. L." (2. ed.)
  44. is in 8.3.3 (p. 266).  In one member function of the list class there is
  45. code like this:
  46.     slink* f = last->next;
  47.     if (f == last)
  48.         last = 0;
  49.     else
  50.         last->next = f->next;
  51.  
  52. I can see no warning in the vicinity telling that the meaning of this code
  53. is implementation dependent or undefined!
  54.  
  55. My opinion:  the idiom is sensible, in many cases even necessary.
  56. It is the pertinent part in the language definition that is broken,
  57. obviously (as explained by Johan above) in order to facilitate
  58. efficient implementation on obsolescent machine architectures.
  59. Was it William Wulf who wrote approximately: "More sins in programming
  60. are committed in the name of efficiency than all other reasons combined,
  61. including sheer stupidity"?
  62.  
  63. ----------------------------------------------------------------------
  64. Markku Sakkinen (sakkinen@jytko.jyu.fi)
  65.        SAKKINEN@FINJYU.bitnet (alternative network address)
  66. Department of Computer Science and Information Systems
  67. University of Jyvaskyla (a's with umlauts)
  68. PL 35
  69. SF-40351 Jyvaskyla (umlauts again)
  70. Finland
  71. ----------------------------------------------------------------------
  72.