Re: deleting an array of objects and undefined behaviour
On 2011-09-23 15:09, Agents Marlow wrote:
I have just come across something I didn't know from the std:
When deleting an array, the dynamic and the static type of the object
must be the same, or the behavior is undefined (C++ Standard 5.3.5/3).
Correct.
I was amazed to discover this. It was revealed to me in a test
question where it had a code fragment and said "what, if anything, is
wrong with this code?". Here is the code:
struct X {
virtual ~X() {}
};
class Y : public X {
};
int main() {
X* p = new Y[2];
delete [] p;
return 0;
}
The above code has undefined behaviour according to the std. But why?
I really don't understand. The usual gotcha when doing polymorphic
deletes is forgetting to make the dtor of the base class virtual but
that has been done here and it's still undefined behaviour!
This is the root of the misunderstanding: The virtual destructor only
helps to make polymorphic deletes of *objects* of the corresponding type
well-defined, but you would need the concept of a virtual destructor for
array objects to make a polymorphic delete of the array well-defined.
But there does not exist such a concept in C++.
You can look at this the following way: array-new allocates a continuous
memory block for the whole number of elements (these are known
statically). Deleting this array via array-delete does not perform any
polymorphic action on the array elements, because they are statically
determined by the type of the array, so it does not help here that X has
a virtual destructor - only the statically determined destructor of the
element type will be invoked.
If one wanted an array of base class pointers then how would one
delete the objects when the time comes? Would it be ok to have a
vector of boost::shared_ptrs?
This would work, because the std::vector will simply invoke the deleter
of the shared_ptr's which knows the correct deleter of it's pointee.
Note the difference: Here you are using an array of *pointer* to items.
But that was not what you used in your original example: There you used
an array of (non-pointer) elements.
Or would that boil down to the above and
thus yield undefined behaviour also? I am worried if the answer to
that is "yes" because I have written such code recently. I hope it
would be ok since the container is a vector rather than a native
array.
This is OK.
Perhaps it is native arrays that are the source of the trouble
for reasons I don't understand.
The problem is one, which cannot happen with std::vector. You either
could form std::vector<X> or std::vector<Y>, but both vectors have no
inheritance relation to each other. They are not even assignable to each
other. Given
std::vector<X> x;
std::vector<Y> y;
neither of
y = x;
x = y;
would be well-formed. The problem with the native array is the implicit
conversion to pointer and the fact that Y* is convertible to X*. Because
of this danger the specialization of std::unique_ptr for arrays is
required to reject pointer arguments to the constructors or the reset
function which are convertible (and not identical) to the pointee type
(The template argument) of std::unique_ptr.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]