home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12313 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  2.0 KB

  1. Path: sparky!uunet!sun-barr!ames!sgi!iphasew!igor!thor!rmartin
  2. From: rmartin@thor.Rational.COM (Bob Martin)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: destruction of temporaries
  5. Message-ID: <rmartin.713716434@thor>
  6. Date: 13 Aug 92 14:33:54 GMT
  7. References: <46140@sunquest.UUCP>
  8. Sender: drk@Rational.COM
  9. Lines: 36
  10.  
  11. bill@sunquest.UUCP (Bill Raves) writes:
  12.  
  13. |We have encountered some widely different behavior in compilers (e.g.
  14. |DEC C++ and cfront) with respect to the destruction of unnamed temporaries
  15. |[...] We also realize that the manifestations of this
  16. |behavior may introduce subtle bugs in code. The question is "How can
  17. |we prevent these problems from getting into production code?".
  18.  
  19. The main thing is to avoid mixing complex construction and destruction
  20. semantics with complex copy semantics.  i.e. if a class cannot be
  21. safely constructed and destructed by the compiler as a temporary, then
  22. don't give the compiler access to its copy constructor or assignment
  23. operator.  (make them private)
  24.  
  25. If you need copy semantics, then you can hide them from the compiler
  26. by adding extra arguments to the copy constructor...
  27.  
  28. Giving the compiler access to the copy semantics of a class is a
  29. design decision which must be made carefully.  It should not be done
  30. in every case.  Many so called "cannonical forms" recommend the
  31. unquestioned inclusion of copy constructors and assigment operators.
  32. I disagree with this approach.  Copy semantics are often too complex
  33. to be allowed into general use.  
  34.  
  35. Whenever you provide a regular copy constructor, you are granting
  36. permission to the compiler to make temporaries.  This must be a
  37. conscious choice, and must be supported by construction and
  38. destruction semantics which are valid in any context.
  39.  
  40.  
  41.  
  42. --
  43. +---Robert C. Martin---+-RRR---CCC-M-----M-| R.C.M. Consulting         |
  44. | rmartin@rational.com |-R--R-C----M-M-M-M-| C++/C/Unix Engineering    |
  45. |     (Uncle Bob.)     |-RRR--C----M--M--M-| OOA/OOD/OOP Training      |
  46. +----------------------+-R--R--CCC-M-----M-| Product Design & Devel.   |
  47.