Как правильно выделять сырую память для размещения в ней объектов?

Question

[floppa322]

Есть ли способ инициализировать "сырую" статическую память под объекты не вызывая их конструкторы?

Пример кода:

template<typename T, size_t capacity>
class Container
{

private:

    alignas(alignof(T)) uint8_t buffer[sizeof(T) * capacity];
    size_t size = 0;

public:

    ~Container()
    {
        for (size_t i = 0; i < size; ++i)
        {
            (reinterpret_cast<T *>(&buffer[sizeof(T) * i]))->~T();
        }
    }

    void add(const T & element)
    {
        new (&buffer[sizeof(T) * size]) T(element);
        ++size;
    }

    const T & get(size_t i)
    {
        return *(reinterpret_cast<T *>(&buffer[sizeof(T) * i]));
    }

};

Вот такой обходной путь пришёл в голову. Но, если честно, смущают reinterpret cast'ы :), хотелось бы без них, через обычный T buffer[capacity], но без вызова конструкторов.

Comments

[Евгений Шатунов]

floppa322

alignas(alignof(T)) uint8_t buffer[sizeof(T) * capacity];

std::byte, т.к. только он и char формально позволят тебе подмену типа на T* без UB. А uint8_t формально является unsigned int длиной в 8 бит. Думаю, char тебе тут не понравится, поэтому предлагаю std::byte.

Посмотри статейки про arena allocator. Для примера могу предложить только доклад в двух частях: [1], [2].
Думаю, тебе будет удобно пользоваться реализацией Free List или Busy List. Эти идиомы применяют при реализации арен.

[floppa322]

Евгений Шатунов, хм, я думал что для signed/unsigned int8_t, signed/unsigned char, и std::byte ( и вроде бы ещё void *) можно reinterpret в обе стороны делать, так как все они байты

[floppa322]

Евгений Шатунов, а, нет, тут ответ есть

Ok, let's get truly pedantic. After reading this, this and this, I'm pretty confident that I understand the intention behind both Standards.

So, doing reinterpret_cast from std::uint8_t* to char* and then dereferencing the resulting pointer is safe and portable and is explicitly permitted by [basic.lval].

However, doing reinterpret_cast from char* to std::uint8_t* and then dereferencing the resulting pointer is a violation of strict aliasing rule and is undefined behavior if std::uint8_t is implemented as extended unsigned integer type.

Ну значит буду использовать вместо (u)int8_t - signed/unsigned char или std::byte

Как я понимаю std::byte предпочтительнее, так как он нужен как раз для случаев с raw memory, чтобы запретить арифметические операции + явно показать в коде, что это именно как сырые байты используется, а не символы или числа

[Евгений Шатунов]

floppa322, все верно. На гитхабе есть такой гист, в нем очень хорошо поясняется проблема UB при подмене типа.
Интерес в том, что даже unsigned char не подходит для подмены. Стандартом разрешены только char и std::byte.

Но ирония нашей работы в том, что разработчикам трансляторов легче в этом месте отойти от стандарта, чем принуждать пользователя транслятора следовать ему. Трансляторы, в основном, понимают твои намерения и обходят вероятность UB поперек правил стандарта когда ты пользуешься uint8_t или чем-то подобным.
Это не значит что твой код от этого перестанет содержать UB, но это и не значит что он будет всегда работать как ты того ожидаешь. Это означает только то, что код не соответствует стандарту языка.

[floppa322]

Евгений Шатунов,

Интерес в том, что даже unsigned char не подходит для подмены. Стандартом разрешены только char и std::byte.

Мб раньше так было, но я вот смотрю в 11.3 присутствует unsigned char

[Евгений Шатунов]

floppa322, о как. Спасибо, я прокараулил это изменение. :)

[floppa322]

Евгений Шатунов, да не за что )

Answer 1

[Армянское Радио]

Нет, если вы не вызвали конструктор и обратились к объекту, вы схлопочете UB, формально говоря.
Да и какой смысл в том, чтобы навыделять памяти, а конструкторы не вызывать? Это нарушает принцип RAII как минимум.
Кстати, именно статической памяти я в вашем коде не увидел.

Так что со стороны это все выглядит как проблема X-Y.

Comments

[floppa322]

Нет, если вы не вызвали конструктор и обратились к объекту, вы схлопочете UB, формально говоря.
Да и какой смысл в том, чтобы навыделять памяти, а конструкторы не вызывать? Это нарушает принцип RAII как минимум.

Обращение к не инициализированной памяти и смысл этих действий, думаю, стоит оставить за рамками вопроса. Можно было бы точно так же обратиться к T * (если бы оно было выделено отдельно в дин. памяти) к ещё неинициализированному объекту и получтиь ub

Кстати, именно статической памяти я в вашем коде не увидел.

Наверное я не совсем корректно выразился, в общем под статической памятью я имел в ввиду, что uint8_t buffer не выделяется отдельно (отдельно от всего объекта Container) в динамической памяти

[Армянское Радио]

floppa322,

Обращение к не инициализированной памяти и смысл этих действий, думаю, стоит оставить за рамками вопроса

Это как раз причина пожалуй 95% падений и дыр в софте. Я еще раз подчеркиваю, что ваш вопрос на первый, второй и третий взгляд выглядит как проблема X-Y - Есть корректные для C++ практики работы с памятью и объектами, например, placement-new.

[floppa322]

Армянское Радио, здесь и используется placement new в методе add, но вместо массива типа T выбран uint8_t (из-за стрикт алиасинга нужно было брать std::byte или signed/unsigned char) чтобы при создании Container'а не вызывался дефолтный конструктор T

[Армянское Радио]

floppa322, тогда с кодом все в порядке.

[Армянское Радио]

floppa322, Однако, я бы не занимался производством этого кода - просто использовал бы std::vector

reserve - выделяет память, не создавая объекты
resize / emplace - создают объекты, когда это необходимо

[floppa322]

Армянское Радио, просто суть вопроса была в том, можно ли как-то хитро создать T buffer[] без вызова конструктора, а то при uint8_t buffer[] приходится использовать reinterpret_cast, что слегка напрягает
при этом вариант выделить отдельно T * buffer = reintrepret_cast(new uint8_t[sizeof(T) * capacity]) тоже особо не привлекает, так как это доп. аллокация

[Армянское Радио]

floppa322, так и используйте std::vector - пусть он делаеь грязную работу у себя внутри

[floppa322]

Армянское Радио, я показал просто идею в коде, в реальном примере не получится использовать никакие обертки
ну и вообще вектор внутри использует allocator.allocate(), который как раз у себя делает что-то вроде T * buffer = reintrepret_cast(new uint8_t[sizeof(T) * capacity])