Re: Is it a good practice to call the destructor explicitly and use placement new(this) in assignment operators?

From:

Pete Becker <pete@versatilecoding.com>

Newsgroups:

comp.lang.c++

Date:

Sun, 13 Dec 2009 14:30:21 -0500

Message-ID:

<-eudnfqVh_ZQ3bjWnZ2dnUVZ_t-onZ2d@giganews.com>

Paavo Helde wrote:

Pete Becker <pete@versatilecoding.com> wrote in
news:mt6dnQGnBLwuirjWnZ2dnUVZ_ohi4p2d@giganews.com:

Paavo Helde wrote:

Michael Tsang <miklcct@gmail.com> wrote in
news:hg2tuh$bmb$1@news.eternal-september.org:

Pete Becker wrote:

No. Think about what happens when someone derives from this class

and

writes a normal assignment operator.

Sorry I forgot to make my assignment operator virtual. Now consider
the following code:

class Foo {
public:
        // default constructor
        Foo();
        // l-value copy constructor
        Foo(const Foo &);
        // destructor
        virtual ~Foo();
        // assignment operator
        virtual Foo &operator=(const Foo &x) {
                if(this != &x) {
                        this->~Foo();
                        new(this) Foo(x);

This slices any derived class object to Foo.

It doesn't even do that. Slicing is well defined:

Foo f = Bar(); // slices the Bar object; f is a valid Foo object

That placement new constructs a Foo object where a Bar object used to
exist, resulting in undefined behavior.

I cannot quite see how this is UB by itself. Consider:

void* p = malloc(sizeof(Bar));
Bar* b = new (p) Bar();
b->~Bar();
Foo* f = new (p) Foo();

Here also a Foo object is constructed where Bar was. Is this UB too?

That's not inside operator=.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)