home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12488 < prev    next >
Encoding:
Text File  |  1992-08-17  |  2.8 KB  |  81 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!mcsun!sunic!ericom!falcon!jonas
  3. From: jonas@beppe.ericsson.se (Jonas Nygren)
  4. Subject: Re: destruction of temporaries
  5. Message-ID: <1992Aug18.071116.3971@ericsson.se>
  6. Sender: news@ericsson.se
  7. Nntp-Posting-Host: falcon.ericsson.se
  8. Reply-To: jonas@beppe.ericsson.se
  9. Organization: Ericsson Telecom AB
  10. References: <23466@alice.att.com>
  11. Date: Tue, 18 Aug 1992 07:11:16 GMT
  12. Lines: 67
  13.  
  14. In article 23466@alice.att.com, ark@alice.att.com (Andrew Koenig) writes:
  15. > In article <1992Aug17.073500.24115@ericsson.se> jonas@beppe.ericsson.se writes:
  16. > 
  17. > > IMO temporaries should survive until end of statement.
  18. > 
  19. > This treatment has two significant disadvantages:
  20. > 
  21. >     1. If I break a statement up into several, it may
  22. >        quietly change its meaning.  Thus, for example, if
  23. >        String::operator const char*() exists, and s and t are
  24. >        of class String, then
  25. > 
  26. >         printf("%s\n", (const char*)(s+t));
  27. >     
  28. >        might work but
  29. > 
  30. >         const char* r = s + t;
  31. >         printf("%s\n", r);
  32. >        
  33. >        might not.
  34.  
  35. Here the programmer must be aware that a conversion takes place and should take
  36. necessary actions. Though, I agree it isn't obvious until you have had this bug.
  37.  
  38. > 
  39. >     2. It is a real pain to implement for statements that
  40. >        generate temporaries inside conditionals.  Thus, for
  41. >        example, in x>0?f(p+q):r, if p+q generates a temporary,
  42. >        and it was necessary to wait until the end of the statement
  43. >        to destroy it, it would also be necessary to remember which
  44. >        branch of the ?: was taken to decide whether or not to
  45. >        destroy it.  There are cases where this can add substantially
  46. >        to execution time.  Moreover, it greately complicates the
  47. >        implementation of exception handling, because it makes it
  48. >        impossible to have a static map from program counter value
  49. >        to offsets of statics to destroy.
  50.  
  51. I get very suspicious when I here about how difficult things are to do in a compiler, e.g. 
  52. I can't accept that extra space in templates x<y<int> > which is claimed to be so difficult to solve. 
  53. (I have never received so many replies as to the article where I claimed this to be a bug).
  54.  
  55. Without any compiler experience I solved this in gcc with one days work. Think of all irritation
  56. it causes to forget this little space, and how relatively simple it can be alleviated.
  57.  
  58. > 
  59. > For these reasons, I think a shorter lifetime than end of statement
  60. > is appropriate for temporaries.  Whether the committee will go that
  61. > way, however, remains to be seen.
  62.  
  63. Perhaps end of statement is not the correct point for destruction of temporaries but I hope you agree
  64. that the small example I showed where:
  65.  
  66.     s2 = s1.sub(2,3);
  67.  
  68. works, but not
  69.  
  70.     s2 = s1.sub(2,3).strip();
  71.  
  72. is a bit to subtle to be acceptable. 
  73.  
  74. > -- 
  75. >                 --Andrew Koenig
  76. >                   ark@europa.att.com
  77.  
  78.  
  79. /jonas
  80.  
  81.