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