home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / cplus / 18192 < prev    next >
Encoding:
Text File  |  1992-12-21  |  3.1 KB  |  75 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!microsoft!wingnut!pauljo
  3. From: pauljo@microsoft.com (Paul Johns)
  4. Subject: Re: Do temps hurt performance of overloaded +
  5. Message-ID: <1992Dec17.210748.24077@microsoft.com>
  6. Date: 17 Dec 92 21:07:48 GMT
  7. Organization: Microsoft, Redmond WA USA
  8. References: <1gofq7INN8q@golden.kaleida.com> 
  9. Lines: 64
  10.  
  11. Whether or not temporaries are created is up the implementation,
  12. provided that the implementation meets the other requirements
  13. of the language.
  14.  
  15. In your case, you've done about all you can to avoid creation
  16. of temporaries:
  17.  
  18.     You've made the parameters to Complex::operator +
  19.     references, which will keep copies of the operands
  20.     from being made for pass-by-value.
  21.  
  22.     You've made the function inline, which allows the
  23.     compiler to optimize away the temporary for the 
  24.     return value if it can.
  25.  
  26. However, for the statement "c = a + b;" the compiler would have to 
  27. construct a temporary for the return value, then use the assignment 
  28. operator to assign it.  I don't think that the compiler is allowed 
  29. to optimize this away.  (Although since you don't define 
  30. Complex::operator =, some compilers could optimize if you hadn't
  31. provided a copy constructor.  Usually if you provide a copy constructor,
  32. you'll need an assignment operator; in your case, the copy constructor
  33. wasn't really necessary.)
  34.  
  35. If you'd waited to declare c, then written "Complex c = a + b;", 
  36. the compiler could eliminate the temporary if it wanted to.  
  37. The elimination of temporaries (and their constructor/destructor 
  38. calls) is the main reason for allowing declarations to appear 
  39. anywhere in C++.
  40.  
  41. As it is now, you'll have constructor calls for c and the temporary,
  42. a call to c's assignment operator, and destructor calls for c and
  43. the temporary.  Changing the assignment to a declaration would
  44. at minimum change the assignment operator call to a copy constructor
  45. call; but it would probably eliminate the assignment operator call
  46. along with the construction and destruction of the temporary.
  47.  
  48. So, your code would be more efficient if you waited to declare c
  49. until you could initialize it.  This is SOP for C++ anyway, and
  50. good programming practice.
  51.  
  52. I'm not sure how smart most compilers will be about passing
  53. "a + b" to operator new.  You may have no choice but to use a
  54. temporary here.
  55.  
  56. Note, however, that in all cases the creation of temporaries
  57. is pretty much comparable to what you'd get for built-in types.
  58.  
  59. There's one other change I'd make:  pass your parameters in by
  60. const reference rather than plain reference.  Starting in version
  61. 2.1, you cannot preform any conversions on parameters that are
  62. passed by plain reference.  That would mean that you could ONLY
  63. pass two Complexes to the operator function--you could not pass
  64. one int or double or anything else.  Also, you could not pass
  65. a const Complex as it is now.  So the prototype would become:
  66.  
  67.     Complex::operator +(const Complex &x, const Complex &y);
  68.  
  69. (On the other hand, using a non-const reference means that your
  70. users will have to make type conversions explicit, which might not
  71. be a bad idea when you're seeking efficiency through not creating
  72. temporaries.)
  73.  
  74. // Paul Johns
  75.