home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 13047 < prev    next >
Encoding:
Text File  |  1992-08-29  |  2.1 KB  |  66 lines
  1. Path: sparky!uunet!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.715101472@thor>
  6. Date: 29 Aug 92 15:17:52 GMT
  7. References: <MCGRANT.92Aug26232410@rascals.stanford.edu> <23563@alice.att.com> <rmartin.715004480@thor> <23583@alice.att.com>
  8. Sender: news@Rational.COM
  9. Lines: 55
  10.  
  11. ark@alice.att.com (Andrew Koenig) writes:
  12.  
  13. |In article <rmartin.715004480@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
  14.  
  15. |> It is in these cases where I would be perfectly happy if the compiler
  16. |> issued a warning, or even an error.
  17.  
  18. |Which cases?  I don't know how to write a compiler smart enough to
  19. |distinguish the innocent cases from the guilty ones.  Surely you're
  20. |not suggesting a warning every time you call a function that returns
  21. |a pointer!
  22. |-- 
  23.  
  24. No, I want a warning every time a temporary gets converted into a
  25. pointer.  
  26.  
  27. In your example:  Given String::operator char*(); 
  28.                     and String String::operator+(const String&);  : 
  29.  
  30. String a,b;
  31. char* c = a+b;
  32.  
  33. An implicit conversion to char* takes place on a temporary.  A warning
  34. should be possible.  
  35.  
  36. Clearly there are cases where the compiler could be thwarted:
  37.  
  38. String a,b,s;
  39. char* c = <some_condition> ? a+b : s;
  40.  
  41. A simplistic compiler might not be able to see this, but it is
  42. detectable.
  43.  
  44.  
  45. String& f(String& x) {return x;}
  46.  
  47. String a,b;
  48. char* c = f(a+b);
  49.  
  50.  
  51. The above is more of a problem, becuase in order to provide the
  52. necessary warning, the compiler must warn whenever a reference to a
  53. temporary is taken.  This would generate warnings even when there was
  54. no danger.  But that's what warnings are all about.
  55.  
  56. What have I forgotten?  Do temporaries present dangers for any context
  57. in which they are not converted to pointers or references?  Are there
  58. any such contexts where the operand of such a conversion cannot be
  59. determined to be a temporary?
  60.  
  61. --
  62. Robert Martin                        Training courses offered in:
  63. R. C. M. Consulting                       Object Oriented Analysis
  64. 2080 Cranbrook Rd.                        Object Oriented Design
  65. Green Oaks, Il 60048 (708) 918-1004       C++
  66.