c++ - C++ 标准对 move 实时对象存储有何看法？

Question

我很好奇在当前 C++ 标准下如何解释以下情况，尤其是在生命周期等方面。它是未定义的行为吗？

首先，让我们从以下定义开始:可重定位对象是一个在其实际内存位置上不变的对象——也就是说，无论指针 this 的值如何，它的状态都保持不变。假设我们有一个可重定位类型 Relocatable(其定义与示例无关)。

然后我们有以下代码(C++17):

typedef std::aligned_storage_t<sizeof(Relocatable)> Storage;

// construct an instance of a relocatable within a storage
auto storage0 = new Storage();
new(storage0) Relocatable(...);

{ 
  // obj is a valid reference
  // should use std::launder() here, but clang doesn't have it yet
  Relocatable& obj = *reinterpret_cast<Relocatable*>(storage0);
}

// move the storage
auto storage1 = new Storage();
memcpy(storage1, storage0, sizeof(Storage));
delete storage0;

{ 
  // ?????? what does the standard say about this?
  Relocatable& obj = *reinterpret_cast<Relocatable*>(storage1);
}

这与预期的一样适用于 GCC 和 Clang(对象只是继续存在于新存储中)。但是，我不完全确定标准是否适用于此。从技术上讲，对象的生命周期尚未结束(未调用析构函数)，并且在 memcpy() 调用后没有对位于旧位置的对象的任何访问。此外，不存在对旧位置的引用/指针。尽管如此，鉴于 C++ 似乎大多数时候都将对象标识和对象存储视为同一事物，因此禁止这样做可能是有原因的。预先感谢所有有见地的评论。

编辑:有人建议 Why would the behavior of std::memcpy be undefined for objects that are not TriviallyCopyable?是这个问题的拷贝。我不确定是不是。首先，我正在 memcpying 存储，而不是对象实例。二、std::is_trivially_copyable<Relocatable>::value实际上评估为 true对于所有实际相关的应用程序。

附言我问这个实际上有一个很好的实际原因。有时让对象只能存在于它们的容器中是有用的——它们不可复制也不可 move 。例如，我目前正在设计一个具有这样属性的优化树数据结构——树节点只能存在于树存储中，它们不能被移出或复制——对它们的所有操作都是通过短暂的引用来执行的。为了防止程序员错误(意外复制/move )，我删除了复制和 move 构造函数。这有一个相当不幸的结果，即节点不能存储在 std::vector 中。放置新的和明确管理的存储可以用来绕过这个限制——但我当然不想做一些不符合标准的事情。

Answer 1

因此，与所有这些类型的问题一样，对象仅在 four situations 中创建:

An object is created by a definition ([basic.def]), by a new-expression, when implicitly changing the active member of a union ([class.union]), or when a temporary object is created ([conv.rval], [class.temporary]).

这段代码:

auto storage1 = new Storage();
memcpy(storage1, storage0, sizeof(Storage));

在 storage1 处为您提供了一个类型为 Storage 的对象，但是此时没有创建类型为 Relocatable 的对象。因此，这:

Relocatable& obj = *reinterpret_cast<Relocatable*>(storage1);

是未定义的行为。期间。

---

为了为其定义行为，我们需要第五种机制来创建对象，例如 P0593 中提出的机制。 :

We propose that at minimum the following operations be specified as implicitly creating objects: [...]

• A call to memmove behaves as if it

  1. copies the source storage to a temporary area

  2. implicitly creates objects in the destination storage, and then

  3. copies the temporary storage to the destination storage.

  This permits memmove to preserve the types of trivially-copyable objects, or to be used to reinterpret a byte representation of one object as that of another object.

• A call to memcpy behaves the same as a call to memmove except that it introduces an overlap restriction between the source and destination.

此提议(或类似提议)对您的代码格式良好是必要的。