Variación sobre el tipo de tema: construcción trivial en el lugar

Sé que este es un tema bastante común, pero aunque la UB típica es fácil de encontrar, no encontré esta variante hasta ahora.

Por lo tanto, estoy tratando de presentar formalmente los objetos Pixel mientras evito una copia real de los datos.

¿Es esto válido?

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.
}

Patrón de uso esperado, muy simplificado:

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

Más específicamente:

• ¿Este código tiene un comportamiento bien definido?
• En caso afirmativo, ¿es seguro usar el puntero devuelto?
• En caso afirmativo, ¿a qué otros Pixeltipos se puede extender? (¿relajando la restricción is_trivial? ¿píxel con solo 3 componentes?).

Tanto clang como gcc optimizan todo el ciclo a la nada, que es lo que quiero. Ahora, me gustaría saber si esto viola algunas reglas de C ++ o no.

Enlace Godbolt si quieres jugar con él.

(nota: no etiqueté c ++ 17 a pesar de std::byteque la pregunta se mantiene usando char)

Es un comportamiento indefinido usar el resultado promotecomo una matriz. Si miramos [expr.add] /4.2 tenemos

De lo contrario, si Papunta a un elemento ide matriz de un objeto de matrizx con nelementos ([dcl.array]), las expresiones P + Jy J + P(donde Jtiene el valor j) apuntan al elemento i+jde matriz (posiblemente hipotético) de xif 0≤i+j≤ny la expresión P - Japunta a ( posiblemente-hipotético) elemento i−jde matriz de xif 0≤i−j≤n.

vemos que requiere que el puntero apunte realmente a un objeto de matriz. Sin embargo, en realidad no tienes un objeto de matriz. Tiene un puntero a un solo Pixelque simplemente sucede que otro lo Pixelssigue en la memoria contigua. Eso significa que el único elemento al que realmente puede acceder es el primer elemento. Intentar acceder a cualquier otra cosa sería un comportamiento indefinido porque ha pasado el final del dominio válido para el puntero.

Ya tiene una respuesta con respecto al uso limitado del puntero devuelto, pero quiero agregar que también creo que necesita std::launderpoder acceder al primero Pixel:

Se reinterpret_castrealiza antes de Pixelcrear cualquier objeto (suponiendo que no lo haga getSomeImageData). Por reinterpret_castlo tanto , no cambiará el valor del puntero. El puntero resultante todavía apuntará al primer elemento de la std::bytematriz pasado a la función.

Cuando cree los Pixelobjetos, se anidarán dentro de la std::bytematriz y la std::bytematriz proporcionará almacenamiento para los Pixelobjetos.

Hay casos en los que la reutilización del almacenamiento hace que un puntero al objeto antiguo apunte automáticamente al nuevo objeto. Pero esto no es lo que está sucediendo aquí, por resultlo que todavía apuntará al std::byteobjeto, no al Pixelobjeto. Supongo que usarlo como si estuviera apuntando a un Pixelobjeto técnicamente será un comportamiento indefinido.

Creo que esto aún se mantiene, incluso si lo hace reinterpret_castdespués de crear el Pixelobjeto, ya que el Pixelobjeto y el std::byteque le proporciona almacenamiento no son interconvertibles por puntero . Entonces, incluso entonces, el puntero seguiría apuntando al objeto std::byte, no al Pixelobjeto.

Si obtuvo el puntero para regresar del resultado de una de las ubicaciones nuevas, entonces todo debería estar bien, en lo que respecta al acceso a ese Pixelobjeto específico .

También debe asegurarse de que el std::bytepuntero esté alineado adecuadamente Pixely que la matriz sea realmente lo suficientemente grande. Por lo que recuerdo, el estándar realmente no requiere que Pixeltenga la misma alineación std::byteo que no tenga relleno.

Además, nada de esto depende de Pixelser trivial o realmente de cualquier otra propiedad del mismo. Todo se comportaría de la misma manera mientrasstd::byte matriz tenga el tamaño suficiente y esté alineada adecuadamente para los Pixelobjetos.