Re: deleting an array of objects and undefined behaviour
On 23/09/11 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).
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!
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? 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. Perhaps it is native arrays that are the source of the trouble
for reasons I don't understand.
Indeed, think about this code:
X* p = new Y[2];
x[1].foo = 1;
That is UB too, because x[1] which is *(x+1) relies on its knowledge of
sizeof(X) to know how much to advance the memory address 'p' -- i.e. if
sizeof(X) < sizeof(Y), it would most probably overwrite data of the
first element instead of what you intended to do. Thus, it is impossible
to treat arrays polymorphically, because you always need the size of the
concrete type of its element to access the array. Just think of 'delete
[]' of one of those other operations that rely on the concrete type,
because of how 'delete []' might be implemented.
However, there are many ways you can implement a safe polymorphic_array
class that would give you the behaviour you want -- I can give further
tips on request.
Note that, as you said, a vector of smart pointers could give you (a bit
inefficiently) the behaviour you want, as long as you don't want further
levels of polymorphism -- remember that a vector itself can not be
treated polymorphically based on its type parameter T, so you could fill
a vector os unique_ptr<X> with pointers to Y, but from that point
onwards there is no further polymorphism you can achieve.
JP
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]