Is such assignment a good idea in C++

Question

A lot of classes has assignment operator (operator=) the same code as in destructor and than very similar code of copy constructor.

So is it good idea to implement the assignment in such way?

Point& operator=(const Point& point)
{
    if(&point != this)
    {
        //Call the destructor
        this->~Point();

        //Make the placement new
        //Assignment is made because some compilers optimise such code as just
        //  new Point;
        Point* p_n = new (this) Point(point);

        //We where placing in this place so pointers should be equal
        assert(p_n == this);
    }
    return *this;
}

Also, this code is not exception safe - in case of exception in `new (this) Point(point)` there will be double destruction. Just use [copy and swap](http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap-idiom) idiom. — Evgeny Panasyuk, Apr 10 '13 at 17:19
@Seagull, Point's ctor (or the type being constructed) can throw. — Jeff Paquette, Apr 10 '13 at 17:23
@Seagull, it is not placement new, it is `Point` constructor. — Evgeny Panasyuk, Apr 10 '13 at 17:23
@EvgenyPanasyuk I was convienced that throwing from constructor is a terrible thing so it should be avoided. — Seagull, Apr 10 '13 at 17:27
@Seagull, "I was convienced that throwing from constructor is a terrible thing" - throwing from **constructor** is wonderful thing! It allows to enstablish object invariants and [use it easily](http://stackoverflow.com/a/810850/1762344). — Evgeny Panasyuk, Apr 10 '13 at 17:33
@Seagull Maybe you are thinking of throwing from a destructor. Now that is a terrible thing. — john, Apr 10 '13 at 18:07
is possible using placement new like that.. but hell that's a pain O_O. placement new is more usefull in other contexts. — CoffeDeveloper, Apr 11 '13 at 05:12

score 6 · Answer 1 · answered Apr 10 '13 at 17:20

6

No. This is a bad idea, even though the C++ Standard uses this kind of thing as an example in a discussion of object lifetime. For a value type like Point it's not so bad, but if you derive from this class, this assignment implementation will change the type of the object from your derived type to Point; if there are virtual functions involved, you'll see a dramatic change in behavior.

answered Apr 10 '13 at 17:20

Pete Becker

74,985
8
76
165

In such case both assignment and copy constructors should be forbidden. My approach uses the copy constructor if it exists. Maybe I have not understood you. – Seagull Apr 10 '13 at 17:25
1

@Seagull - I thought your point was to implement the assignment operator. Implementing it this way sets a trap for users of such a class, and the result is deadly. Try it! – Pete Becker Apr 10 '13 at 17:32

score 3 · Accepted Answer · edited May 23 '17 at 10:25

Herb Sutter has addressed this in one of his GotW articles. I recommend that you read it. His conclusion:

The original idiom is full of pitfalls, it's often wrong, and it makes life a living hell for the authors of derived classes. I'm sometimes tempted to post the above code in the office kitchen with the caption: "Here be dragons."

From the GotW coding standards:
prefer writing a common private function to share code between copying and copy assignment, if necessary; never use the trick of implementing copy assignment in terms of copy construction by using an explicit destructor followed by placement new, even though this trick crops up every three months on the newsgroups (i.e., never write:
T& T::operator=( const T& other )
{
    if( this != &other)
    {
        this->~T();             // evil
        new (this) T( other );  // evil
    }
    return *this;
}

Is such assignment a good idea in C++

2 Answers2

Linked