为什么不能保证 memcpy 对于非 POD 类型是安全的？

Question

我从 SO 上发布的几个问题中了解到这一段。

我不太明白为什么不能保证memcpy 对于非 POD 类型是安全的。我的理解是memcpy 只是按位复制。

以下是标准的引用

对于POD类型T的任何对象（基类子对象除外），无论该对象是否拥有T类型的有效值， 构成对象的底层字节（1.7）可以复制到char或unsigned char.41的数组中）如果内容 char 或 unsigned char 的数组被复制回对象中，对象随后应保持其原始 价值。

# define N sizeof (T)
char buf[N];
T obj ; // obj initialized to its original value
std :: memcpy (buf , & obj , N); // between these two calls to std::memcpy,
                                 // obj might be modified
std :: memcpy (& obj , buf , N); // at this point, each subobject of obj of 
                                 // scalar type holds its original value

Answer 1

总的来说，问题在于对象不仅会引入数据，还会引入行为。

通过手动复制数据，我们可能会破坏对象的固有行为，这可能依赖于复制构造函数。

一个很好的例子是任何 shared 或 unique 指针 - 通过复制它，我们破坏了我们在使用它时与该类达成的“交易”。

无论复制过程在语义上是否正确，这样做背后的想法都是错误的，并且违反了对象编程范式。

示例代码：

/** a simple object wrapper around a pthread_mutex
 */
class PThreadMutex
{
   public:
    /** locks the mutex. Will block if mutex is already locked */
    void lock();

    /** unlocks the mutex. undefined behavior if mutex is unlocked */
    void unlock();

   private:
    pthread_mutex_t m_mutex;

};

/** a simple implementation of scoped mutex lock. Acquires and locks a Mutex on creation,
 * unlocks on destruction
 */
class ScopedLock
{
  public:
    /** constructor specifying the mutex object pointer to lock
     * Locks immediately or blocks until lock is free and then locks
     * @param mutex the mutex pointer to lock
     */
    ScopedLock ( PThreadMutex* mutex );

    /** default destructor. Unlocks the mutex */
    ~ScopedLock ();

    /** locks the mutex. Will block if mutex is already locked */
    void unlock();


  private:

    PThreadMutex* m_mutex;

    // flag to determine whether the mutex is locked
    bool m_locked;

    // private copy constructor - disable copying
    ScopedLock(ScopedLock &mutex) { (void)mutex; /* to get rid of warning */ };

};

如果您复制ScopedLock 类，手动解锁它，然后恢复该值并在构造函数中执行另一次解锁，这将导致未定义的行为（或至少在析构函数中出现 EPERM 错误）。

Answer 2

想象一个类，它持有一些指向缓冲区的指针，如下所示：

class Abc {
    public:
    int* data;
    size_t n;
    Abc(size_t n)
    {
        this->n = n;
        data = new int[n];
    }

    // copy constructor:
    Abc(const Abc& copy_from_me)
    {
        n = copy_from_me.n;
        data = new int[n];
        memcpy(data, copy_from_me.data, n*sizeof(int));
    }
    Abc& operator=(const Abc& copy_from_me)
    {
        n = copy_from_me.n;
        data = new int[n];
        memcpy(data, copy_from_me.data, n*sizeof(int));
        return *this;
    }

    ~Abc()
    {
        delete[] data;
    }
} ;

如果你只是 memcopy 它的一个构造实例，你会得到两个实例指向同一个缓冲区data，因为它们在data 指针中具有相同的缓冲区地址。如果您在一个实例中修改数据，它也会在另一个实例中被修改。

这意味着您并没有真正将它克隆到两个独立的类中。此外，如果您随后删除这两个类，缓冲区将从内存中释放两次，这将导致崩溃。 所以这个类必须定义一个复制构造函数，而你必须使用构造函数来复制它。

Answer 3

尝试按位复制std::shared_ptr<>。你可能会发现你的程序经常在你面前崩溃。

任何类的拷贝构造函数做的不是按位拷贝，你都会遇到这个问题。在std::shared_ptr<> 的情况下，它会复制指针但不会增加引用计数，因此您最终会提前释放共享对象及其引用计数，然后在复制的shared_ptr 尝试时爆炸减少释放的引用计数。

---

更新： 有人指出，这并不能完全回答问题，这是公平的，因为我主要解决了将 shared_ptr 复制到 shared_ptr 的想法，而不是 shared_ptr 到 char[] 并返回再次。但是，这个原则仍然成立。

如果您按位将 shared_ptr 复制到 char[]，为 shared_ptr 分配不同的值，然后将 char[] 复制回来，最终结果可能是泄漏一个对象并双重删除另一个对象，即, UB。

同样的情况也可能发生在 POD 上，但这将是程序逻辑中的一个错误。只要程序理解并适应这样的事件，按位复制回修改后的 shared_ptr 的等效 POD 将是完全有效的。对 std::shared_ptr 这样做通常是行不通的。

Answer 4

例如，假设您正在编写一个String 类。该类的任何实例都应包含指向某个动态分配的char 数组的指针。如果你 memcopy 这样一个实例，那么这两个指针将是相等的。对一个字符串的任何修改都会影响另一个字符串。

Answer 5

C++11 注意：问题中的引用是该规则的一个相当旧的版本。从 C++11 开始，要求是可轻松复制，这比 POD 弱得多。

---

memcpy 可以用于任何对象。您会得到对象的按位图像。

如果对象不是 POD，则不能将图像用作与原始对象相同类型的图像，因为生命周期规则需要先完成初始化。

在这种情况下，图像只是一堆字节。这可能仍然有用，例如检测对象内部表示随时间的变化，但只有对字节有效的操作（例如两个图像之间的比较）是合法的，而不是需要原始类型对象的操作。