4

As far as I am aware, memcpy into uninitialized storage cannot safely be used to create an copy of the source object.

However, in this thread from last year on the open-std WG21 "ub" list, a participant refers to the new memcpy lifetime-initiation rules:

This doesn’t seem to rise to the level of a bug report, but it might be relevant to the new memcpy lifetime-initiation rules. Will they ascribe some static type to the source and destination bytes?

Based on the context of the question and small amount of type-erasure example code, it appears that it may be related to creating new objects in aligned_storage via memcpy.

Search as I might, I can't find a reference to the new rules. I'm particularly curious if they only apply to replacing the contents of an already created object, or if they change the situation around the potential creation of an object in uninitialized memory.

curiousguy
  • 8,038
  • 2
  • 40
  • 58
BeeOnRope
  • 60,350
  • 16
  • 207
  • 386

2 Answers2

5

The wording has changed a bit, but the general idea remains the same. From intro.object:

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

Those are the only four ways to create an object in C++. memcpy does not fall into any of those four conditions and hence it does not now (and never has before) create lifetime (implicitly changing the active member of a union can be done via = only, not via memcpy).

The quote refers to a hypothetical future change to the standard that would bless memcpy with such ability in certain situations. There was a very long thread on the subject earlier in the year as well.

Barry
  • 286,269
  • 29
  • 621
  • 977
  • Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackoverflow.com/rooms/157388/discussion-on-answer-by-barry-what-are-the-changes-if-any-to-the-memcpy-lifeti). – Brad Larson Oct 24 '17 at 14:24
1

The wording has changed some more in C++20. The change is based on p0593r6 which is retroactively applied to all versions since C++98 inclusive, so though the wording just happens to appear in C++20 spec, it is still true for C++17 as well as for C++98 etc.

From intro.object:

  1. The constructs in a C++ program create, destroy, refer to, access, and manipulate objects. An object is created by a definition, by a new-expression, by an operation that implicitly creates objects (see below)...

...

  1. Further, after implicitly creating objects within a specified region of storage, some operations are described as producing a pointer to a suitable created object. These operations select one of the implicitly-created objects whose address is the address of the start of the region of storage, and produce a pointer value that points to that object, if that value would result in the program having defined behavior. If no such pointer value would give the program defined behavior, the behavior of the program is undefined. If multiple such pointer values would give the program defined behavior, it is unspecified which such pointer value is produced.

See also this SO answer.

Community
  • 1
  • 1
Amir Kirsh
  • 12,564
  • 41
  • 74
  • @DavisHerring Well the modification is based on [p0593r6](http://wg21.link/p0593r6) which is retroactively applied to all versions since C++98 inclusive - added this clarification into the answer. – Amir Kirsh May 26 '20 at 06:01
  • Sorry, I phrased that badly. It’s true that it’s a DR and that compilers will, to the extent that they take any actual action as a result, apply it in all language versions (even though that’s beyond the formal power of a DR). However, the question was asking about changes supposedly included in C++17 (as published), so it’s important to distinguish what actually happened (which you have now done!). – Davis Herring May 26 '20 at 07:26