AMDG On 03/20/2011 02:30 AM, pavel wrote:
Steven wrote on Saturday, March 19, 2011 at 18:40:26:
Actually, I got it from n3242 which is a recent C++0x draft. are you sure that this draft is going to become the final version of std?
Nope. It definitely will get some more updates. However, I think it highly unlikely that this restriction will be removed. It already existed for array delete, and this makes the two more consistent.
"In the first alternative (delete object), if the static type of the operand is different from its dynamic type, the static type shall be a base class of the operand’s dynamic type and the static type shall have a virtual destructor or the behavior is undefined." i believe this part concerns slicing as when one deletes an object of some derived class D using pointer to the base class B
this way ~D() destructor has no chance to be executed and we have the whole bunch of unwanted effects
furthermore when '::delete operator()' function is called the compiler may miscalculate the size of the object to be deleted since sizeof(D) may differ from sizeof(B) and the deallocation function likely be supplied with wrong size argument which again may cause unexpected effects
in my variant of implementation all destructors involved are trivial (read: they are never called)
Not guaranteed.
and the global deallocation function ('::operator delete()') is never called on the operand of the delete expression
Irrelevant.
so i believe it shouldn't cause undefined behavior anyway
Undefined behaviour does not mean that the code will do bad things. It means that the standard does not specify what happens. Don't try to second guess the implementation like this. Just because you can't think of anything that can go wrong, does not mean that it's safe. In Christ, Steven Watanabe