Variação no tema de punição de tipo: construção trivial no local

Sei que esse é um assunto bastante comum, mas, por mais fácil que seja o UB típico, não encontrei essa variante até agora.

Então, estou tentando introduzir formalmente objetos Pixel, evitando uma cópia real dos dados.

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

Padrão de uso esperado, altamente simplificado:

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

Mais especificamente:

• Esse código tem um comportamento bem definido?
• Se sim, torna seguro usar o ponteiro retornado?
• Em caso afirmativo, para que outros Pixeltipos ele pode ser estendido? (relaxando a restrição is_trivial? pixel com apenas 3 componentes?).

Tanto o clang quanto o gcc otimizam todo o loop para o nada, que é o que eu quero. Agora, eu gostaria de saber se isso viola algumas regras do C ++ ou não.

Godbolt link, se você quiser brincar com ele.

(nota: apesar de não ter marcado o c ++ 17 std::byte, porque a pergunta continua sendo usada char)

É um comportamento indefinido para usar o resultado promotecomo uma matriz. Se olharmos para [expr.add] / 4.2 , temos

Caso contrário, se Papontar para um elemento ida matriz de um objeto da matrizx com nelementos ([dcl.array]), as expressões P + Je J + P(where Jtem o valor j) apontam para o elemento i+jda matriz (possivelmente hipotético) de xif 0≤i+j≤ne a expressão P - Japonta para ( possivelmente hipotético) elemento i−jde matriz de xif 0≤i−j≤n.

vemos que ele requer que o ponteiro aponte para um objeto de matriz. Na verdade, você não possui um objeto de matriz. Você tem um ponteiro para um único Pixelque, por acaso, possui outro Pixelsna memória contígua. Isso significa que o único elemento que você pode acessar é o primeiro. Tentar acessar qualquer outra coisa seria um comportamento indefinido, porque você passou do final do domínio válido para o ponteiro.

Você já tem uma resposta sobre o uso limitado do ponteiro retornado, mas quero acrescentar que também acho que você precisa std::launderacessar o primeiro Pixel:

O reinterpret_casté feito antes de qualquer Pixelobjeto é criado (supondo que você não fazê-lo em getSomeImageData). Portanto reinterpret_cast, não alterará o valor do ponteiro. O ponteiro resultante ainda apontará para o primeiro elemento da std::bytematriz passado para a função.

Quando você cria os Pixelobjetos, eles serão aninhados na std::bytematriz e a std::bytematriz fornecerá armazenamento para os Pixelobjetos.

Há casos em que a reutilização do armazenamento faz com que um ponteiro para o objeto antigo aponte automaticamente para o novo objeto. Mas não é isso que está acontecendo aqui, por resultisso ainda apontará para o std::byteobjeto, não para o Pixelobjeto. Eu acho que usá-lo como se estivesse apontando para um Pixelobjeto será tecnicamente um comportamento indefinido.

Eu acho que isso ainda é válido, mesmo se você fizer o reinterpret_castdepois de criar o Pixelobjeto, uma vez que o Pixelobjeto e o std::byteque fornece armazenamento para ele não são intercambiáveis ​​por ponteiro . Portanto, mesmo assim, o ponteiro continuaria apontando para std::byteo Pixelobjeto , não para ele .

Se você obteve o ponteiro para retornar do resultado de um dos novos posicionamentos, tudo deve ficar bem, no que diz respeito ao acesso a esse Pixelobjeto específico .

Além disso, você precisa garantir que o std::byteponteiro esteja alinhado adequadamente Pixele que a matriz seja realmente grande o suficiente. Tanto quanto me lembro, o padrão não exige realmente que Pixeltenha o mesmo alinhamento std::byteou que não tenha preenchimento.

Além disso, nada disso depende de Pixelser trivial ou realmente qualquer outra propriedade dele. Tudo se comportaria da mesma maneira, desde que a std::bytematriz tenha tamanho suficiente e esteja adequadamente alinhada para os Pixelobjetos.