To be human is to fear what's unknow or uncertain. It's not surprising that there is wide-spread fear about memcpy() on a class object, or its effect on v-table on different implementations. Because most people simply do not know what's going on underneath.

There is nothing misterious about v-table. They are merely class data member(s), in the form of function pointers, of the base class where the virtual function(s) is(are) declared. They are part of the base class, just like the rest of class data members, although they are not quite as visible. So, yes, the v-table do gets copied over when you are copying or moving objects.

In doing object sorting, no object creation or destruction should be involved. We are just moving objects around from one memory location to another location.

It is highly likely that by merely shifting an object in the memory would not change the property of the object. The object should look just the same before and after the shift. In such case it is perfectly OK to just memcpy to swap objects or move them to a different location.

If in the rare case, the object's property DO depend on its memory location. Then such objects can not be copied, and no proper copy constructor can be written. Because you would have to copy the object into exactly the same memory location to make it look and behave exactly the same!!!

In such rare cases, qsort() would not work properly, but neither std::sort() would work. Since std::sort() requires an appropriate copy constructor, but I already said no proper copy constructor can be written since once the object is copied to a different location, it no longer behave the same even every thing else is the same!!!