In the general case, yes, there will be problems. Both
memmove are bitwise operations with no further semantics. That might not be sufficient to move the object*, and it is clearly not enough to copy.
In the case of the copy it will break as multiple objects will be referring to the same dynamically allocated memory, and more than one destructor will try to release it. Note that solutions like
shared_ptr will not help here, as sharing ownership is part of the further semantics that
memmove don’t offer.
For moving, and depending on the type you might get away with it in some cases. But it won’t work if the objects hold pointers/references to the elements being moved (including self-references) as the pointers will be bitwise copied (again, no further semantics of copying/moving) and will refer to the old locations.
The general answer is still the same: don’t.
* Don’t take move here in the exact C++11 sense. I have seen an implementation of the standard library containers that used special tags to enable moving objects while growing buffers through the use of
memcpy, but it required explicit annotations in the stored types that marked the objects as safely movable through
memcpy, after the objects were placed in the new buffer the old buffer was discarded without calling any destructors (C++11 move requires leaving the object in a destructible state, which cannot be achieved through this hack)