home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 13002 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  2.4 KB

  1. Path: sparky!uunet!portal!cup.portal.com!Aurelius
  2. From: Aurelius@cup.portal.com (Mark Christian Barnes)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: complex classes and temporary destruction.
  5. Message-ID: <64821@cup.portal.com>
  6. Date: Thu, 27 Aug 92 23:44:12 PDT
  7. Organization: The Portal System (TM)
  8. Distribution: world
  9. References: <MCGRANT.92Aug26232410@rascals.stanford.edu>
  10.   <23563@alice.att.com>
  11. Lines: 52
  12.  
  13. Andrew Koenig writes:
  14.  
  15. | Don't worry, the issues under discussion will not affect well-behaved
  16. | programs such as this.  The real problems come about when, say, a String
  17. | class has operator const char() that returns a pointer to the internal
  18. | representation of the String.  That then raises the problem:
  19. | String s, t;
  20. | // ...
  21. |         const char* p = s + t;
  22. | and now, the question is when the temporary representing `s + t' is
  23. | destroyed.  The point is that destroying that temporary invalidates p, 
  24. | so it suddenly becomes an issue of great concern.
  25. | --
  26. |           --Andrew Koenig
  27.  
  28.  Have the temporary "inherit" (for lack of a better word) the
  29. storage class of p. If p is an auto variable then 's+t' should
  30. be auto too. Destroy p and 's+t' together. If p is static, then
  31. perhaps have 's+t' be static as well, onc instance of 's+t'
  32. gets re-used each time the statement is executed.
  33.  
  34.  For global variables, you have to watch out for all kinds of
  35. unknowns. In this case, maybe a destructor should be called
  36. right before p is assigned a new value. This assumes that the
  37. old value of p is no longer needed and the new temporary is not
  38. able to re-use the 's+t' object. Also 's+t' may be assigned to more
  39. than one variable by this time, and therefore should remain around.
  40.  
  41. String s = "hello";    // global String
  42. const char *pS1, *pS2;    // global pointers
  43.  
  44. void not_main ( void )
  45. {
  46.  pS1 = s + s;        // assign temporary to global
  47.  pS2 = pS1;        // save a copy
  48.  pS1 = s + s + s;    // assign another temp to global, re-use 's+s'?
  49.             // or maybe destruct 's+s' and create 's+s+s'?
  50.             // But no!, pS1 points to 's+s' also. Since
  51.             // the pointers are always in scope, when
  52.             // do the temporaries get destructed??
  53. }
  54.  
  55.  This bit of an example may show that the two "temporaries"
  56. could be destroyed or re-used before the assignment. But of
  57. course they may be aliased again outside the scope of this
  58. module. About all that makes sense to me is that they are
  59. not actually "temporary" at all, but are unnamed globals,
  60. whose usage needs to be tracked by the compiler.
  61.  
  62.             Regards, Aurelius@cup.portal.com
  63.