Variation des Typ-Punning-Themas: In-Place-Trivial-Konstruktion

Ich weiß, dass dies ein ziemlich häufiges Thema ist, aber so leicht die typische UB zu finden ist, habe ich diese Variante bisher nicht gefunden.

Daher versuche ich, Pixelobjekte formell einzuführen und dabei eine tatsächliche Kopie der Daten zu vermeiden.

Ist das gültig?

struct Pixel {
    uint8_t red;
    uint8_t green;
    uint8_t blue;
    uint8_t alpha;
};

static_assert(std::is_trivial_v<Pixel>);

Pixel* promote(std::byte* data, std::size_t count)
{
    Pixel * const result = reinterpret_cast<Pixel*>(data);
    while (count-- > 0) {
        new (data) Pixel{
            std::to_integer<uint8_t>(data[0]),
            std::to_integer<uint8_t>(data[1]),
            std::to_integer<uint8_t>(data[2]),
            std::to_integer<uint8_t>(data[3])
        };
        data += sizeof(Pixel);
    }
    return result; // throw in a std::launder? I believe it is not mandatory here.
}

Erwartetes Verwendungsmuster, stark vereinfacht:

std::byte * buffer = getSomeImageData();
auto pixels = promote(buffer, 800*600);
// manipulate pixel data

Genauer:

• Hat dieser Code ein genau definiertes Verhalten?
• Wenn ja, ist es sicher, den zurückgegebenen Zeiger zu verwenden?
• Wenn ja, auf welche anderen PixelTypen kann es erweitert werden? (Lockerung der is_trivial-Einschränkung? Pixel mit nur 3 Komponenten?).

Sowohl clang als auch gcc optimieren die gesamte Schleife ins Nichts, was ich will. Jetzt möchte ich wissen, ob dies gegen einige C ++ - Regeln verstößt oder nicht.

Godbolt-Link, wenn Sie damit herumspielen möchten.

(Hinweis: Ich habe c ++ 17 trotz nicht markiert std::byte, da die Frage mit verwendet wird char)

Es ist ein undefiniertes Verhalten, das Ergebnis von promoteals Array zu verwenden. Wenn wir uns [expr.add] /4.2 ansehen , haben wir

WennPix andernfalls auf ein Array-Element eines Array-Objekts mit nElementen ([dcl.array]) verweist, zeigen die Ausdrücke P + Jund J + P(wobei Jder Wert j) auf das (möglicherweise hypothetische) Array-Element i+jvon xif 0≤i+j≤nund der Ausdruck P - Jauf das ( möglicherweise hypothetisches Array-Element i−jvon xif 0≤i−j≤n.

Wir sehen, dass der Zeiger tatsächlich auf ein Array-Objekt zeigen muss. Sie haben jedoch kein Array-Objekt. Sie haben einen Zeiger auf eine einzelne Pixel, der zufällig andere Pixelsim zusammenhängenden Speicher folgen. Das heißt, das einzige Element, auf das Sie tatsächlich zugreifen können, ist das erste Element. Der Versuch, auf etwas anderes zuzugreifen, wäre ein undefiniertes Verhalten, da Sie das Ende der gültigen Domäne für den Zeiger überschritten haben.

Sie haben bereits eine Antwort bezüglich der eingeschränkten Verwendung des zurückgegebenen Zeigers, aber ich möchte hinzufügen, dass Sie meiner Meinung std::laundernach auch auf den ersten zugreifen müssen Pixel:

Das reinterpret_castgeschieht , bevor ein PixelObjekt erstellt wird (vorausgesetzt , Sie nicht tun so in getSomeImageData). Daher reinterpret_castwird der Zeigerwert nicht geändert. Der resultierende Zeiger zeigt weiterhin auf das erste Element des std::byteArrays, das an die Funktion übergeben wurde.

Wenn Sie die PixelObjekte erstellen , werden sie im Array verschachteltstd::byte und das std::byteArray stellt Speicher für die PixelObjekte bereit.

Es gibt Fälle, in denen die Wiederverwendung von Speicher dazu führt, dass ein Zeiger auf das alte Objekt automatisch auf das neue Objekt zeigt. Aber das ist nicht das, was hier passiert, also resultwird immer noch auf das std::byteObjekt hingewiesen, nicht auf das PixelObjekt. Ich denke, es so zu verwenden, als würde es auf ein PixelObjekt zeigen, wird technisch gesehen ein undefiniertes Verhalten sein.

Ich denke, dass dies immer noch gilt, selbst wenn Sie dies reinterpret_castnach dem Erstellen des PixelObjekts tun , da das PixelObjekt und das std::byte, das Speicher dafür bereitstellt, nicht zeigerinterkonvertierbar sind . Selbst dann würde der Zeiger weiter auf std::bytedas PixelObjekt zeigen , nicht auf das Objekt.

Wenn Sie den Zeiger erhalten haben, um aus dem Ergebnis einer der neuen Platzierungen zurückzukehren, sollte alles in Ordnung sein, was den Zugriff auf dieses bestimmte PixelObjekt betrifft.

Außerdem müssen Sie sicherstellen, dass der std::byteZeiger entsprechend ausgerichtet ist Pixelund dass das Array wirklich groß genug ist. Soweit ich mich erinnere, erfordert der Standard nicht wirklich, dass er Pixeldie gleiche Ausrichtung hat std::byteoder keine Polsterung hat.

Auch hängt nichts davon davon ab Pixel, trivial zu sein oder wirklich irgendeine andere Eigenschaft davon. Alles würde sich gleich verhalten, solange das std::byteArray ausreichend groß und für die PixelObjekte geeignet ausgerichtet ist .