home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 13085 < 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: complex classes and temporary destruction.
  5. Message-ID: <rmartin.715267018@thor>
  6. Date: 31 Aug 92 13:16:58 GMT
  7. References: <MCGRANT.92Aug26232410@rascals.stanford.edu>   <23563@alice.att.com> <64821@cup.portal.com> <23578@alice.att.com> <64878@cup.portal.com>
  8. Sender: news@Rational.COM
  9. Lines: 57
  10.  
  11. Aurelius@cup.portal.com (Mark Christian Barnes) writes:
  12.  
  13. |Andrew Koenig writes:
  14.  
  15. ||
  16. ||char* I(char* x) { return x; }
  17. ||
  18. ||The function I (for identity) just returns its argument, but to make things
  19. ||difficult, it is compiled separately.  Now, you would like
  20. ||
  21. ||char* p = s+t;
  22. ||
  23. ||to cause the temporary for s+t to stick around as long as p does,
  24. ||but what are you going to do about this?
  25. ||
  26. ||        char* p = I(s+t);
  27. ||
  28. ||There's no way to know what I() does, so what basis do you have for
  29. ||letting the lifetime of p affect that of s+t?
  30.  
  31. | But Andrew, you have changed the statement completely. The
  32. |temporary 's+t' is no longer even being assigned to 'p'. It is
  33. |constructed as a parameter for function (or macro) 'I'. In this
  34. |case I would suggest that 's+t' is an auto variable with a scope
  35. |limited to 'I'.
  36.  
  37. | I know that this means that your example will not work under
  38. |this interpretation. Well I don't think it should. The perpetual
  39. |problem of aliasing, to which pointers contribute, should not be
  40. |solved by the compiler. I feel that the programmer should pay
  41. |attention to what he/she is doing.
  42.  
  43. But, the problem of when to "safely" destroy temporaries is all
  44. wrapped up in how to deal with aliases.  And I disagree that the
  45. compiler should ignore the creation of an alias to a temporary.  It
  46. should at least warn that such aliases are being created.
  47.  
  48. | In your example, an expression is evaluated and passed
  49. |(on the stack) as the parameter to a function. The function
  50. |'I' returns another value of type pointer to char. There should
  51. |not be any assumption that the parameter and the return value
  52. |have anything in common. You, as the programmer, know that 'I'
  53. |returns the parameter. Therefore, you should also insure that
  54. |any parameters passed to 'I' are of the appropriate storage
  55. |class and scope for the uses that you intend.
  56.  
  57. Yes, but an alias to the temporary was created before the function was
  58. called.  The expression s+t created a temporary, and its address was
  59. taken (alias created) to be passed into the function.  The compiler
  60. should issue a warning at this point.
  61.  
  62.  
  63. --
  64. Robert Martin                        Training courses offered in:
  65. R. C. M. Consulting                       Object Oriented Analysis
  66. 2080 Cranbrook Rd.                        Object Oriented Design
  67. Green Oaks, Il 60048 (708) 918-1004       C++
  68.