Why can't classes with a destructor be memcpy'ed

Question

The rules of C++ say that it's legal and will work to copy an object or a POD type using memcpy.

They further say that a POD can't have a (non-trivial) destructor. Why is this and why would the mere addition of a destructor change the class in such a way that using memcpy would not work?

// Perfectly fine to copy using memcpy
struct data
{
    int something;
    float thing;
};

// Not allowed to copy using memcpy
int var;

struct data
{
    int something;
    float thing;
    ~data() { var = 1; }
};

Why would simply adding the destructor make it impossible to memcpy the struct's data? I can't imagine that this would require altering the data layout in any way.

I'm not interested in being told don't do this, I have no intention to do so... I understand I can't do this because "the standard says so" but I'm wondering what the reason the standard says so is as it doesn't seem a necessary restriction to me and want to understand the reasons.

EDIT People seem to be misunderstanding my question. I'm not asking if it's a good idea or not to use memcpy. I'm asking what is the reasoning behind making it illegal if there is a non-trivial destructor. I can't see what difference it makes and want to understand why this restriction exists. Most of the reasons I've been given about it being a bad idea apply just as much if there is a destructor or not.

Answer 1

In layman's terms:

Why would simply adding the destructor make it impossible to memcpy the struct's data?

It doesn't make it impossible, just illegal.

I can't imagine that this would require altering the data layout in any way.

Probably won't, but it's allowed to. Because the class is no longer a POD (i.e. a c struct) it's now a c++ class.

Classes have different rules to PODs. Since we cannot predict how the compiler will go about coding them up, we can no longer reason about the outcome of memcpy.

Answer 2

Non-trivial destructors typically reverse some non-trivial action performed in a constructor (or other member functions) that affect the object state.

memcpy() copies the bits that make up the object. If the behavior of a constructor would give a different set of bits, then the destructor on that object will try to reverse some action that has not actually occurred.

A typical example is a class who's constructors allocate some resource (e.g. memory), other member functions ensure that resource remains in a sane state, and the destructor releases that resource. Copying such an object using memcpy() will copy the handle of that resource, rather than creating a new instance of that resource for the copied object [which is what the copy constructor of such an object typically does]. The destructor - eventually - will be invoked for both the original and copied objects, and the resource will be released twice. For memory (e.g. allocated using C's malloc() or C++'s operator new) releasing twice gives undefined behaviour. For other resources (file handles, mutexes, other system resources) the result varies, but - on must systems - it is generally inadvisable to deallocate a single something twice.

The other problem is that a class may have base classes, or have members, that themselves have non-trivial constructors and destructors. Even if the class itself has a constructor which does nothing, destroying an object invokes destructors of all members and bases. Copying such an object using memcpy() affects those base classes or members in the way I describe above.

Answer 3

Only objects which are trivially copyable can be copied using memcpy. A class with non-trivial destructor is not trivially copyable.

Suppose for an example, your class has a pointer as one of its member. You allocate space for that pointer in the constructor of the class. Now, you can do a variety of things in the non-trivial destructor like deleting the space you allocated. By memcpy you'll be copying the entire structure bit by bit. So two instances will be trying to delete the same pointer when their destructors are called.

Answer 4

The problem is usually that when you have a destructor which does something, you also should have a copy constructor/assignment operator (look up "Rule of 3" for this).

When you memcpy, you will skip these copy operation and this can have some consequences.

E.g. you have a pointer to an object and delete it in the constructor. You then should also specify a copy operation so you copy the pointer/object there too. If you use memcpy instead you have 2 pointers to the same instance and the second destruction would cause an error.

The compilers cannot know what you do in your destructors and if special behavior is needed so it's pessimistic and is seen as a non-POD type anymore. (even if you do nothing in the destructor).

A similar thing happens with the generation of move-assignment/move-constructors when you declare a destructor in a class in c++11.

Answer 5

This is because memcpy provides a shallow copy and if you have a non trivial dtor it is probably because your object is the owner of some resource, then a shallow copy would not provide you the right copy semantic (duplicate the ownership). Think about some structure with a pointer to something inside, the dtor should (probably) free the resource when the struct disappear, but a shallow copy will let you with a dangling pointer.

Answer 6

The problem arises when memory is owned by the class: you should not memcpy a class that owns memory (even if it has no destructor) take for instance:

https://ideone.com/46gFzw

#include <iostream>
#include <memory>
#include <cstring>

struct A
{
  std::unique_ptr<int> up_myInt;
  A(int val)
  :
    up_myInt(std::make_unique<int>(val))
  {}
};

int main()
{
    A a(1);
    {
      A b(2);
      memcpy(&a, &b, sizeof(A));
      std::cout << *a.up_myInt << std::endl;
      //b gets deleted, and the memory b.up_myInt points to is gone
    }
    std::cout << *a.up_myInt << std::endl;
    return 0;
}

which results in

stdout

2
0

stderr

*** Error in `./prog': double free or corruption (fasttop): 0x08433a20 ***

As b goes out of scope, the data it owned is deleted, a points to the same data, hence fun times (same happens if your class contains basically any other stl container so never ever memcpy an stl containter either.)