<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Oct 5, 2013 at 5:38 PM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">> This doesn’t mean by chance there is no destructor so nothing bad happens,<br>
> it mean if there is no destructor so, according to the standard, the<br>
> compiler should consider the object alive until the memory is released.<br>
<br>
</div>There are multiple sub-objects under discussion here and only one of<br>
them has a trivial destructor.<br>
<br>
The standard appears to have stopped specifying behaviour at 5.3.5<br>
("thou shalt have a virtual destructor") so the entire discussion is<br>
moot. But I think it's difficult to argue that, had it skipped that<br>
bit and gone on to define behaviour for your case, either the<br>
my_destroy_default_impl or Toto objects would still be alive.<br>
<span class=""><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Ah, thanks. It seems that this is actually re-iterated later on, so let's have both quotes:<br><br>§5.3.5 Delete [expr.delete]<br><br>3/ In the first alternative (delete object), if the static type of the object to be deleted is different from its dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined.<br>
<br><br>§12.5 Free store [class.free]<br><br>4 [...] Otherwise, if the delete-expression is used to deallocate a class object whose static type has a virtual destructor, the deallocation function is the one selected at the point of definition of the dynamic type’s virtual destructor (12.4). Otherwise, if the delete-expression is used to deallocate an object of class T or array thereof, the static and dynamic types of the object shall be identical and the deallocation function’s name is looked up in the scope of T.<br>
<br><br></div><div class="gmail_extra">So the Standard is unambiguous: either `delete` shall be called on a pointer to the most derived object or, if called on a base sub-object, the destructor of the corresponding sub-class shall be virtual.<br>
<br><br></div><div class="gmail_extra">On the other, the good news for you Emmanuel is the first sentence of §12.5/4 I cited: when calling `delete base`, the `delete` operator called is looked up at the point of definition of the dynamic type's virtual destructor. Thus your usecase of linking two libraries with incompatible new/delete pairs should work as-is providing you take care that the virtual dispatch to the destructor selects the right definition of operator delete.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">-- Matthieu<br></div></div>