home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12353 < prev    next >
Encoding:
Internet Message Format  |  1992-08-14  |  2.4 KB
  1. Path: sparky!uunet!olivea!mintaka.lcs.mit.edu!ai-lab!life.ai.mit.edu!tmb
  2. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: destruction of temporaries
  5. Message-ID: <TMB.92Aug14212640@arolla.idiap.ch>
  6. Date: 15 Aug 92 01:26:40 GMT
  7. References: <46140@sunquest.UUCP>
  8. Sender: news@ai.mit.edu
  9. Reply-To: tmb@idiap.ch
  10. Followup-To: comp.lang.c++
  11. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  12.     Perceptive)
  13. Lines: 53
  14. In-reply-to: bill@sunquest.UUCP's message of 12 Aug 92 23:31:55 GMT
  15.  
  16.  
  17.    One suggestion is to promulgate stylistic guidelines which caution
  18.    against troublesome usage. For example, Jim Adcock has suggested
  19.    (<70784@microsoft.UUCP>) "NEVER rely on unnamed temporaries to do
  20.    anything...", but this would seem to erode the expressiveness of the
  21.    language: constructs like "foo(x + y)" and "foo()[i]" would no longer
  22.    be permissible. Henricson & Nyquist suggest "Do not write code which is
  23.    dependent on the lifetime of a temporary object" but this seems too
  24.    vague, especially for novice programmers, and seems to require us to
  25.    know the details of the implementation.  What *specific* guidelines
  26.    would you suggest for avoiding potential problems with unnamed tem-
  27.    poraries?
  28.  
  29. I think any of these problems can only occur if you use pointers to
  30. temporary objects, or pointers to their contents.
  31.  
  32. Assume the following definitions are in effect:
  33.  
  34.     Str::operator char*() ...
  35.     Str operator+(Str&,Str&) ...
  36.     void f(char*) ...
  37.     void g(Str*) ...
  38.     char *Str::h() ...
  39.  
  40. Then, the following expressions are bad:
  41.  
  42. (1)    f((char*)(x+y));
  43. (2)    g(&(x+y));
  44. (3)    f((x+y).h());
  45. (4)    f(x+y);
  46.  
  47. (Str::pointer() returns some pointer to the interior of the object).
  48.  
  49. Now, (1) and (2) can be avoided by not casting to a pointer types or
  50. taking the address of anything other than a variable.
  51.  
  52. (3) is a little trickier. Generally, any member function that returns
  53. a pointer type should be viewed with suspicion. But you really have to
  54. know what you are doing:
  55.  
  56.     char *Str::h1() { return new char; }
  57.     char *Str::h2() { return this->data; }
  58.  
  59. Of these, h1 is OK, while h2 could fail for a temporary. The same is
  60. true for functions that return pointers and take reference arguments:
  61.  
  62.     char *h3(Str &x) { return x.data; }
  63.  
  64. (4) can be avoided by not defining cast operators that convert your
  65. class to a pointer type; doing so is inviting trouble, even if it
  66. looks cute.
  67.  
  68.                     Thomas.
  69.