Вариация на тему типа прокалывания: на месте тривиальная конструкция

Я знаю, что это довольно распространенная тема, но насколько легко найти типичный UB, я не нашел этот вариант до сих пор.

Итак, я пытаюсь официально представить объекты Pixel, избегая при этом фактической копии данных.

Это действительно?

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

Ожидаемая схема использования, сильно упрощенная:

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

Более конкретно:

• Этот код имеет четко определенное поведение?
• Если да, то безопасно ли использовать возвращенный указатель?
• Если да, то на какие другие Pixelтипы он может быть распространен? (ослабление ограничения is_trivial «пиксель только с 3 компонентами»).

И clang, и gcc оптимизируют весь цикл до небытия, чего я и хочу. Теперь я хотел бы знать, нарушает ли это некоторые правила C ++ или нет.

Ссылка Godbolt, если вы хотите поиграть с ней.

(примечание: я не пометил c ++ 17, несмотря на то std::byte, что вопрос касается использования char)

Неопределенное поведение использовать результат promoteв качестве массива. Если мы посмотрим на [expr.add] /4.2 мы имеем

В противном случае, если Pуказывает на элемент массива iобъекта массиваx с nэлементами ([dcl.array]), выражения P + Jи J + P(где Jимеет значение j) указывает на (возможно, гипотетический) элементу массива i+jиз , xесли это 0≤i+j≤nи выражение P - Jуказывает на ( возможно , -гипотетический) элемент массива i−jиз xесли 0≤i−j≤n.

мы видим, что для этого требуется указатель, чтобы фактически указывать на объект массива. На самом деле у вас нет объекта массива. У вас есть указатель на сингл, Pixelкоторый случайно оказался рядом с другим Pixelsв непрерывной памяти. Это означает, что единственный элемент, к которому вы можете получить доступ, это первый элемент. Попытка получить доступ ко всему остальному была бы неопределенным поведением, потому что вы вышли за пределы допустимого домена для указателя.

У вас уже есть ответ относительно ограниченного использования возвращаемого указателя, но я хочу добавить, что я также думаю, что вам нужно std::launderдаже иметь доступ к первому Pixel:

reinterpret_castДелается до того , как Pixelсоздается объект (если вы не сделаете это в getSomeImageData). Поэтому reinterpret_castне изменит значение указателя. Полученный указатель все равно будет указывать на первый элемент std::byteмассива, переданный функции.

Когда вы создаете Pixelобъекты, они будут вложены в std::byteмассив, и std::byteмассив будет предоставлять хранилище для Pixelобъектов.

В некоторых случаях повторное использование хранилища приводит к тому, что указатель на старый объект автоматически указывает на новый объект. Но это не то, что здесь происходит, поэтому resultвсе равно будет указывать на std::byteобъект, а не на Pixelобъект. Я предполагаю, что использование его так, как если бы оно указывало на Pixelобъект, технически будет неопределенным поведением.

Я думаю, что это все еще сохраняется, даже если вы делаете reinterpret_castпосле создания Pixelобъекта, так как Pixelобъект и то, std::byteчто обеспечивает хранение для него, не взаимозаменяемы с указателем . Так что даже тогда указатель будет продолжать указывать std::byteна Pixelобъект , а не на объект.

Если вы получили указатель для возврата из результата одного из новых объектов размещения, то все должно быть в порядке, если речь Pixelидет о доступе к этому конкретному объекту.

Также вам нужно убедиться, что std::byteуказатель правильно выровнен Pixelи массив действительно достаточно большой. Насколько я помню, стандарт на самом деле не требует, чтобы он Pixelимел такое же выравнивание std::byteили не имел отступов.

Также ничто из этого не зависит от того, Pixelявляется ли оно тривиальным или действительно каким-либо другим его свойством. Все будет вести себя одинаково, пока std::byteмассив имеет достаточный размер и соответствующим образом выровнен для Pixelобъектов.