🚀 go-pugleaf

William Sears <sears@zork.tiac.net> wrote:
>The current default definition of assignment for C++ produces 
>incorrect code in most cases where either a copy constructor or
>a destructor present, thus requiring the programmer to override
>the default

>The proposed change:
>
>
>       If there is:
>
>              a.  No assignment operator
>              b.  Either a user defined copy constructor
>                    OR Defined destructor.
>          
>       Then the definition of Class operator=(const Class& other) is:
>
>               if (this==&src)
>                   return *this;
>               Class::~Class();
>               new (this) Class(src);
>               return *this;
>

    Unfortunately, this definition of assignment will 
badly corrupt programs using inheritance. The reason
hinges on the fact that constructors install virtual table
pointers -- asssignment operators do not affect virtual tables.

    To see the problem, consider:

    struct B { 
       virtual void something();
       B(B const &) {}
       virtual ~B() {}
       // generated assignment
   };

   struct D : B { virtual void something(); };

   D d1, d2;
   B &b1 = d1, &b2 = d2;
   b1 = b2; // slicing

Slicing is dangerous anyhow, because any data in the LHS
derived class is not changed by the assignment --
assignment operators in bases should be protected to
prevent this happening.

However, the effect of the current generated assignment
in these circumstances is to mess up USER CLASS INVARIANTS.

The effect of the proposal WOULD CHANGE THE TYPE OF THE OBJECT.
A much more serious problem.

The problem with the proposal is that one would have to
override the default in base classes, whereas with the
status quo one overrides in derived classes.

[In favour of the proposal is that it doesn't
assign bases twice -- it works well for leaf classes]

-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au




---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]