home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 13240 < prev    next >
Encoding:
Text File  |  1992-09-02  |  2.0 KB  |  41 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!secapl!Cookie!frank
  3. From: frank@Cookie.secapl.com (Frank Adams)
  4. Subject: Re: destruction of temporaries
  5. Message-ID: <1992Sep02.225757.27678@Cookie.secapl.com>
  6. Date: Wed, 02 Sep 1992 22:57:57 GMT
  7. References: <1992Aug25.175751.8117@microsoft.com> <1992Aug28.221841.149034@Cookie.secapl.com> <23585@alice.att.com>
  8. Organization: Security APL, Inc.
  9. Lines: 30
  10.  
  11. In article <23585@alice.att.com> ark@alice.UUCP () writes:
  12. >In article <1992Aug28.221841.149034@Cookie.secapl.com> frank@Cookie.secapl.com (Frank Adams) writes:
  13. >
  14. >> I don't claim to have a complete solution to the problem.  However, for the
  15. >> specific case   c ? a+b : a   where a+b creates a temporary, I would be
  16. >> tempted (as a compiler writer) to always return a temporary: a+b if c is
  17. >> true, and a copy of a otherwise.  This solves the problem of not knowing
  18. >> whether a temporary has been created.
  19. >
  20. >I'm afraid it doesn't solve the problem.  For example, suppose `a' is of type
  21. >const char*, `b' is of type String, and String has one of those problematic
  22. >conversions to const char*.  Now, let's modify your example a tiny bit and
  23. >look at c?(const char*)(a+b):a.
  24. >
  25. >This expression always returns a value of type const char*, but that's not
  26. >where the problem likes: the problem is in the temporary of type String
  27. >yielded by the subexpression a+b.  The value of (const char*)(a+b) is valid
  28. >only so long as that temporary stays around, so any games you play with
  29. >the const char* values themselves won't affect that.
  30.  
  31. The problem in this case is the (const char *) conversion, not the ?:
  32. expression.  You would have essentially the same problem with only the
  33. conversion.  Remember, I didn't claim to be solving the whole problem, just
  34. ?:.
  35.  
  36. I consider a "conversion" (or any other function) which returns a pointer to
  37. an internally-allocated object to be suspect, anyhow; except in the case
  38. where the object returned is of a class with its own memory management.  (On
  39. the other hand, I don't off hand have any good alternative for the cases
  40. where you want to use it.)
  41.