home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 13087 < prev    next >
Encoding:
Internet Message Format  |  1992-08-31  |  2.7 KB
  1. Path: sparky!uunet!UB.com!igor!thor!rmartin
  2. From: rmartin@thor.Rational.COM (Bob Martin)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Destruction of temporaries
  5. Message-ID: <rmartin.715267769@thor>
  6. Date: 31 Aug 92 13:29:29 GMT
  7. References: <rmartin.715004480@thor> <23583@alice.att.com> <rmartin.715101472@thor> <1992Aug29.184025.328@frumious.uucp>
  8. Sender: news@Rational.COM
  9. Lines: 58
  10.  
  11. pat@frumious.uucp (Patrick Smith) writes:
  12.  
  13. |rmartin@thor.Rational.COM (Bob Martin) writes:
  14. ||String& f(String& x) {return x;}
  15. ||
  16. ||String a,b;
  17. ||char* c = f(a+b);
  18. ||
  19. ||The above is more of a problem, becuase in order to provide the
  20. ||necessary warning, the compiler must warn whenever a reference to a
  21. ||temporary is taken.  This would generate warnings even when there was
  22. ||no danger.  But that's what warnings are all about.
  23.  
  24. |My feeling is that if a compiler did this, the meaningful warnings
  25. |would be buried in a landslide of warnings for completely safe cases.
  26. |For example,
  27.  
  28. |   String operator+(const String& s1, const String& s2);
  29.  
  30. |   String a, b, c, d;
  31. |   d = a + b + c;
  32.  
  33. |In evaluating the second sum, the reference s1 is bound to the
  34. |temporary representing a+b.  So the compiler would issue a warning,
  35. |according to your rule.
  36.  
  37. Ideed.  But I think the warning is still useful.  The difficulty is
  38. that an alias to a temporary can refer to the temporary, long after it
  39. has been destroyed, regardless of which strategy is eventually used to
  40. destroy it.  (With the exception of GC).  Moreover, it is not
  41. realistic to suppose that the compiler can track the usage of such
  42. aliases in order to warn against misuse.  But, the compiler *can* warn
  43. us whenever such aliases are created. 
  44.  
  45. Such warnings are useful in my opinion, because they point at
  46. potential problem areas.  If there are lots of them produced, there
  47. are lots of potential problem areas to review.
  48.  
  49. Some compilers may wish to deal with the deluge of warnings by
  50. implementing #pragmas which specifically inhibit warnings about the
  51. creation of aliases as arguments to specific functions.  For example:
  52.  
  53.  #pragma Supress_Alias_Warning String::operator+(const String&, const String&)
  54.  
  55. This could prevent the compiler from warning about aliases created
  56. when forming the arguments to functions which are known to be benign.
  57. The above #pragma would eliminate all the warnings from your example,
  58. but would still pass warnings about other aliases.
  59.  
  60. This exposes the alias problem, and puts responsibility for it square
  61. on the programmer.  It also allows the compiler to destroy temporaries
  62. at the earliest possible moment.
  63.  
  64. --
  65. Robert Martin                        Training courses offered in:
  66. R. C. M. Consulting                       Object Oriented Analysis
  67. 2080 Cranbrook Rd.                        Object Oriented Design
  68. Green Oaks, Il 60048 (708) 918-1004       C++
  69.