home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / cplus / 13592 < prev    next >
Encoding:
Text File  |  1992-09-13  |  3.2 KB  |  76 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!sun-barr!ames!haven.umd.edu!darwin.sura.net!wupost!usc!sdd.hp.com!hp-cv!hp-pcd!hp-vcd!nuntius
  3. From: John Matthews <jm@vcd.hp.com>
  4. Subject: Default assignment semantics
  5. Message-ID: <BuJs8K.Hzr@vcd.hp.com>
  6. Sender: news@vcd.hp.com (News user)
  7. Organization: Hewlett-Packard
  8. X-Useragent: Nuntius v1.1a5
  9. Date: Mon, 14 Sep 1992 02:57:55 GMT
  10. Lines: 64
  11.  
  12. As I understand it, if a class does not have an explicitly defined
  13. assignment operator, a default assignment operator is generated
  14. by the compiler. This default operator simply does a member-wise
  15. assignment. As has been pointed out many times, these semantics
  16. are dangerous for classes that have pointers to dynamically created
  17. objects as fields.
  18.  
  19. It seems to me that a more robust default assignment operator would
  20. have the following semantics:
  21.  
  22.   1) Invoke the destructor of the object being assigned to.
  23.   2) Invoke the copy constructor on the object being assigned
  24.       to, taking as an argument the object being assigned from.
  25.  
  26. In the case where a class has no user defined destructor or copy
  27. constructor, the above semantics devolves to member-wise
  28. assignment, just as before. However, for classes that have
  29. user defined destructors and copy constructors, (as all classes
  30. that have pointers to dynamic objects should) the above
  31. semantics generates code that is much safer. Take for example a
  32. String class, whose constructor allocates a character buffer for
  33. a string, and whose destructor frees that buffer. The user-defined
  34. copy constructor would construct its String object with a separately
  35. allocated character buffer of the same size as its String argument,
  36. and perform a string copy between the two character buffers.
  37.  
  38. Under the current default assignment operator semantics, for every  
  39. String assignment made, a character buffer is 'leaked', and two
  40. pointers to the same buffer are made.  Under the above semantics,
  41. however, the assignee String first has its buffer deallocated, and
  42. then recieves a new buffer from the copy constructor, just like you
  43. would expect.
  44.  
  45. Since this is not the semantics of the current assignment operator,
  46. a user defined assignment operator needs to be defined whenever
  47. a user defined destructor or copy constructor exists for a class.
  48. Thus what I want to do in most of my assignment operators is
  49. explicitly invoke the corresponding destructor and copy constructor.
  50.  
  51. I know how to explicitly call a destructor on an object, but how do
  52. you explicitly call a copy constructor on what used to be an object?
  53. The only way I know of to do this is to overload operator new() with a
  54. pointer argument. The overloaded new() operator would just return
  55. the pointer. I could then write an assignment operator like the following
  56. for any class X:
  57.  
  58.         X& X::operator=( const X& from )
  59.         {
  60.                   this->~X();                                   // invoke
  61. destructor.
  62.                   new(this) X(from);                       // invoke copy
  63. constructor.
  64.                   return( *this );
  65.         }
  66.  
  67. However overloading new seems a little kludgy when all I want to
  68. do is call a constructor on a specific object reference.
  69.  
  70. Please reply via this notes group, I don't currently have access to an
  71. email server.
  72.  
  73. Thanks,
  74. John Matthews
  75. Hewlett-Packard
  76.