home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12524 < prev    next >
Encoding:
Text File  |  1992-08-18  |  2.5 KB  |  78 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!sdl!adk
  3. From: adk@Warren.MENTORG.COM (Ajay Kamdar)
  4. Subject: Re: destruction of temporaries
  5. Message-ID: <1992Aug18.205211.16789@Warren.MENTORG.COM>
  6. Organization: Mentor Graphics Corp. - IC Group
  7. References: <1992Aug17.073500.24115@ericsson.se> <23466@alice.att.com> <1992Aug17.211508.6634@lucid.com>
  8. Date: Tue, 18 Aug 1992 20:52:11 GMT
  9. Lines: 67
  10.  
  11. In article <1992Aug17.211508.6634@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
  12. >In article <23466@alice.att.com>, ark@alice.att.com (Andrew Koenig) writes:
  13. >|> This treatment [end of statement] has two significant disadvantages:
  14. >|> 
  15. >|>     1. If I break a statement up into several, it may
  16. >|>        quietly change its meaning.  Thus, for example, if
  17. >|>        String::operator const char*() exists, and s and t are
  18. >|>        of class String, then
  19. >|> 
  20. >|>         printf("%s\n", (const char*)(s+t));
  21. >|>     
  22. >|>        might work but
  23. >|> 
  24. >|>         const char* r = s + t;
  25. >|>         printf("%s\n", r);
  26. >|>        
  27. >|>        might not.
  28. >
  29. >And I feel that I should be able to add a { } around an expression
  30. >statement without changing its meaning.  In other words I ought
  31. >to be able to further transform the above to
  32. >
  33. >        const char* r = "" ;
  34. >        if ( 1 ) { r = s+t ; } 
  35. >        printf("%s\n", r) 
  36. >
  37. >
  38. >Even "end of block" (the latest anyone has proposed) makes
  39. >this example undefined.
  40. >
  41.  
  42. As Andrew Koenig and Jerry Schwarz point out, "end of statement" and
  43. "end of block" treatment of temporaries is not good enough.
  44.  
  45. The ARM also mentions a "end of function" treatment, but goes on to reject
  46. that too. However, I am not convinced by the ARM's explanation for not
  47. adopting the "end of function" approach. On page 270, the ARM gives the
  48. following example and uses that example to reject this approach:
  49.  
  50.     const char* f()
  51.     {
  52.         String x("foo");
  53.         String y("bar");
  54.         return x + y;    // still not guaranteed to work
  55.     }
  56.  
  57. However, note that I can put myself in exactly the same situation even
  58. without any temporaries being involved.
  59.     const char *f()
  60.     {
  61.         String x("foobar");
  62.         return x;    // not guaranteed to work either
  63.     }
  64.  
  65. So why would the ARM consider the example with a temporary sufficient
  66. reason to reject the "end of function" approach? To me it appears that
  67. the "end of function" approach for temporaries would not cause any more
  68. difficulties or program bugs than those that can already occur even without
  69. temporaries. So why not reconsider that approach?
  70.  
  71. - Ajay
  72.  
  73. -- 
  74. I speak for none but myself.
  75.  
  76. Ajay Kamdar                               Email : ajay_kamdar@mentorg.com
  77. Mentor Graphics, IC Group (Warren, NJ)    Phone : (908) 580-0102
  78.