home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / cplus / 13629 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  2.3 KB
  1. Path: sparky!uunet!think.com!barmar
  2. From: barmar@think.com (Barry Margolin)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Default assignment semantics
  5. Date: 14 Sep 1992 19:06:03 GMT
  6. Organization: Thinking Machines Corporation, Cambridge MA, USA
  7. Lines: 38
  8. Distribution: usa
  9. Message-ID: <192nqrINN8tb@early-bird.think.com>
  10. References: <BuJs8K.Hzr@vcd.hp.com> <1992Sep14.152055.5825@sunb10.cs.uiuc.edu>
  11. NNTP-Posting-Host: telecaster.think.com
  12.  
  13. In article <1992Sep14.152055.5825@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
  14. >>Thus what I want to do in most of my assignment operators is
  15. >>explicitly invoke the corresponding destructor and copy constructor.
  16. >
  17. >*****>    Ah..."most."  There are occasions, as I've already pointed out,
  18. >    when one doesn't want the d'tor called.  To have this
  19. >    flexibility is probably part of the reason the assignment
  20. >    operator is as it is.
  21.  
  22. No one is suggesting taking that flexibility away from you.
  23.  
  24. I like the original poster's idea.  Why force the programmer to write three
  25. functions when the compiler can often infer the third one from the first
  26. two?  Sure, it may be possible to do better than calling the destructor and
  27. copy constructor, but the current default assignment operator is almost
  28. always wrong when these are defined.
  29.  
  30. If the language isn't changed, I would suggest that compiler implementors
  31. add a warning when they see a class with a copy constructor and destructor,
  32. but no assignment operator.
  33.  
  34. On a related note, I think that something needs to be done about the fact
  35. that assignment operators aren't inherited.  I think the default assignment
  36. operator for a class derived from classes with user-defined assignment
  37. operators, and which doesn't have its own copy constructor or destructor
  38. (so that it doesn't fall into the above case) should be to invoke the base
  39. classes' assignment operators and then perform memberwise assignment on the
  40. members that it adds.  And if this isn't done, I think compilers should
  41. warn when a class derives from a base with an assignment operator but
  42. doesn't also overload assignment; if a base class needs special assignment
  43. semantics, it seems pretty unlikely that the default semantics would be
  44. appropriate for the derived class.
  45.  
  46. -- 
  47. Barry Margolin
  48. System Manager, Thinking Machines Corp.
  49.  
  50. barmar@think.com          {uunet,harvard}!think!barmar
  51.