Vonhttp: //en.cppreference.com/w/cpp/string/byte/memcp:

Wenn die Objekte nicht @ si TriviallyCopyable (z. B. Skalare, Arrays, C-kompatible Strukturen) ist das Verhalten undefiniert.

Bei meiner Arbeit haben wir @ verwendstd::memcpy für eine lange Zeit, um Objekte, die nicht TriviallyCopyable sind, bitweise auszutauschen, mit:

void swapMemory(Entity* ePtr1, Entity* ePtr2)
{
   static const int size = sizeof(Entity); 
   char swapBuffer[size];

   memcpy(swapBuffer, ePtr1, size);
   memcpy(ePtr1, ePtr2, size);
   memcpy(ePtr2, swapBuffer, size);
}

nd hatte nie irgendwelche Problem

Ich verstehe, dass es trivial ist, zu missbrauchenstd::memcpy mit nicht TriviallyCopyable-Objekten und verursachen undefiniertes Verhalten im Downstream. Allerdings meine Frage:

Warum würde das Verhalten vonstd::memcpy selbst undefiniert sein, wenn es mit nicht TriviallyCopyable-Objekten verwendet wird? Warum hält es die Norm für notwendig, dies anzugeben?

AKTUALISIERE

Die Inhalte vonhttp: //en.cppreference.com/w/cpp/string/byte/memcp wurde als Antwort auf diesen Beitrag und die Antworten auf den Beitrag geändert. Die aktuelle Beschreibung lautet:

Wenn die Objekte nicht @ si TriviallyCopyable (z. B. Skalare, Arrays, C-kompatible Strukturen) ist das Verhalten undefiniert, sofern das Programm nicht von den Auswirkungen des Destruktors des Zielobjekts abhängt (das nicht von @ ausgeführt wirmemcpy) und die Lebensdauer des Zielobjekts (das beendet, aber nicht von @ gestartet wimemcpy) wird auf andere Weise gestartet, z. B. durch Placement-New.

PS

Kommentar von @Cubbi:

@ RSahu Wenn etwas UB Downstream garantiert, macht es das gesamte Programm undefiniert. Aber ich stimme zu, dass es in diesem Fall möglich zu sein scheint, UB zu umgehen und cppreference entsprechend zu modifizieren.