Re: Is it a good practice to call the destructor explicitly and use
placement new(this) in assignment operators?
On Dec 14, 6:17 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
Pete Becker <p...@versatilecoding.com> wrote
innews:avCdnWPGG-KB8bjWnZ2dnUVZ_oli4p2d@giganews.com:
Paavo Helde wrote:
Pete Becker <p...@versatilecoding.com> wrote in news:-
eudnfqVh_ZQ3bjWnZ2dnUVZ_t-on...@giganews.com:
Paavo Helde wrote:
Pete Becker <p...@versatilecoding.com> wrote in
news:mt6dnQGnBLwuirjWnZ2dnUVZ_ohi4p2d@giganews.com:
Paavo Helde wrote:
Michael Tsang <mikl...@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=.
It also doesn't make any further use of b.
I presume this means no UB in the last example.
Then, how the operator= is any different? Clearly, just
being a member function should not affect anything. For
example, several people (incl. James Kanze) advocate using
"delete this;" from inside a member function. This clearly
invalidates the object, but as long as it is not accessed
any more, there should be no UB.
As long as there is no further use of the this pointer, *nor* of
any other pointer to the object, there is no problem. (Note
that "delete this" is only appropriate for certain types of
objects, which explicitly manage their own lifetime, and will
take the appropriate steps in their destructor to ensure that no
other pointers to them remain. Of course, in a lot of
applications, no other types should be dynamically allocated to
begin with.)
operator= isn't usually called on objects that are going to
be thrown away immediately.
The problem, of course, isn't that you're still going to use the
object. The problem is that you've changed its type.
In no way do I advocate actually using this, but here is an
example of using the object after assignment. UB or not UB?
#include <iostream>
class Foo {
public:
Foo(int x): x_(x) {}
void operator=(const Foo& b) {
void* p = static_cast<void*>(this);
this->~Foo();
new (p) Foo(b.x_);
}
virtual ~Foo() {}
virtual void f() {
std::cout << "Foo(" << x_ << ")\n";
}
protected:
int x_;
};
class Bar: public Foo {
public:
Bar(int x, int y): Foo(x), y_(y) {}
virtual void f() {
std::cout << "Bar(" << x_ << ", " << y_ << ")\n";
}
private:
int y_;
};
int main() {
Foo* p = new Bar(42,43);
std::cout << "Before assignment: ";
p->f();
*p = Foo(31);
std::cout << "After assignment: ";
p->f();
delete p;
}
Undefined behavior. The standard does allow constructing a new
object where an old one existed. But pointers to the old one
are only valid if the storage exactly overlays the old one (the
case here, maybe), the new object has the same type (modulo
cv-qualifiers) as the old one, and neither are base class
subobjects. If you want to see why, consider modifying Bar as
follows:
struct BarBase { int i; /* take some space */ };
class Bar : private BarBase, public Foo
{
// as before...
};
Now what do you get?
--
James Kanze