Является ли такой способ выделения массива объектов на хипе идиоматичным?

Question

[floppa322]

Если требуется работа с голой памятью (например, какое-то апи требует тип T *), без использования векторов и прочего, является ли такой способ создания элементов массива на куче предпочтительным:

Point * points = reinterpret_cast<Point *>(new (std::align_val_t(alignof(Point))) std::byte[SIZE * sizeof(Point)]);

Перед таким:
Point ** points = new Point*[SIZE];

Ведь во мало того, что во втором случае придётся SIZE раз обращаться к аллокатору, так ещё и каждый элемент будет в рандомном месте на хипе (плохо по кэшу), в то время, как в 1-м случае все элементы будут лежать подряд в памяти

P.S.: Point не полиморфный объект
Хотя, если бы Point был полиморфный и максимальный размер ребёнка был бы < CACHE_LINE_SIZE хотя бы раза в 3-4, то можно было бы и в таком случае разместить их всех в массиве с константным смещением равным максимальному размеру ребенка, по идее быстрее бы работало

Comments

[Wataru]

Я не понимаю, как вы сравниваете эти два способа. Первый, хоть и через жопу, выделяет массив из Point. Второй же выделяет массив указателей (на Point, но это не важно).

Можно было бы сравнивать с:
Point * points = new Point[SIZE];

Это сильно лучше вашей простыни. И так делают.

[floppa322]

Wataru, так а если нужно вызвать конструкторы от разных аргументов, то это не подойдёт же
ну то есть если у Point нет конструктора по умолчанию

[Wataru]

floppa322, А вот это уже интересный момент. В этом случае, да. выделить непрерывный кусок памяти и руками заполнять объекты - может быть даже имеет смысл. Это важное уточнение, его стоит дописать к вопросу.

Но я бы завел пустой вектор и делал в нем emplace_back с нужными параметрами. При чем, у вектора можно сделать reserve сначала и тогда перевыделений памяти не будет. Внутри, конечно, в итоге будет простыня, похожая на то, что у вас вначале, но не в библиотечном коде лучше такого не писать.

[floppa322]

floppa322, А вот это уже интересный момент. В этом случае, да. выделить непрерывный кусок памяти и руками заполнять объекты - может быть даже имеет смысл. Это важное уточнение, его стоит дописать к вопросу.

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

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

floppa322, грубо говоря, в первом случае ты изобрел Memory Pool. Не Object Pool, т.к. объекты у тебя начинают и завершают время своей жизни, а выделенная под них память является сырой.

К тебе вопрос. Что такое "боле идиоматичный" способ?
Первый пример у тебя почти-почти реализует шаблон проектирования. В это время второй пример у тебя демонстрирует решение бытовой потребности в "стиле сишечки". Там у тебя не ** должен быть, а std::vector на должный умный указатель.
В этом контексте мне не понятно, о чем именно ты спрашиваешь. Ясность должно внести толкование используемого тобой термина.

[floppa322]

Евгений Шатунов, смотрел недавно код кишков UE4 и там почти везде было сделанно именно 1-м способом, без вектора (даже без их внутреннего аналога вектора) и умных указателей, и оно было использовано не в контексте пула, а как обычный массив на куче. Поэтому такой вопрос назрел
Насчёт "идиоматичный" я имел в виду, что "принято чаще так делать", хотя судя по ответам идиотматичным как раз является вариант с вектором

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

floppa322, UE не показатель хорошего кода. Совсем не показатель. Даже наоборот, хоть в целом инструмент и пользуется популярностью, в деталях же он кишит совершенно неподходящими к месту решениями.
Они там очень часто пишут шиворот-навыворот, буквально не оставляя никакой возможности заимствовать их код как есть.

Принято же у людей разное. В разных сословиях разные порядки. Гулять между сословиями можно вполне свободно, просто придерживаясь тех или иных порядков.
У некоторых людей принято обосновывать свои решения и прибегать к знанию архитектуры ПО на всех уровнях разработки. У некоторых людей принято лабать на сишечке даже в плюсах, без особых рассуждений о будущем написанного кода. Кое-кто вообще ежедневно и во всеуслышание твердит, что "говнокод захватит этот мир", попутно и со всем усердием делая свой посильный вклад в процесс этого захвата.
Просто выбери свою сторону. Я вот выбрал знание и следование стандарту, знание архитектуры и выбор инструментов через обоснование. Не все люди одобряют мой выбор. И так будет всегда, что бы ты ни выбрал.

[floppa322]

Евгений Шатунов, хотел добавить насчёт Pool'а: этот паттерн же используется для объектов, создание которых относительно дорогое, чтобы вместо создания и разрушения были методы acquire() и release() соответственно. Где acquire() будет модифицировать "пару" полей объекта, приводя его в боевое состояние, а release() - сбрасывать состояние
Если честно, не совсем понял, как это связано с тем примером ), мб мы про разные пулы говорим )

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

floppa322, сейчас ты описал Object Pool. Это другое.
Memory Pool полноценно создает и уничтожает объекты, контролируя только выделенную под них память в своих страницах. Именно пулы памяти используются для дешевого выделения больших количеств объектов с полиморфизмом. Очень часто пул памяти выступает источником памяти для абстрактной фабрики.
При этом для пула памяти характерно именно то, что в ячейку странички по выравниванию и размеру входит объект любого типа из полиморфной иерархии. Т.е. все как ты и описал в своем вопросе.

[floppa322]

Евгений Шатунов, ок, буду знать, спасибо за информацию :)

[floppa322]

Евгений Шатунов, ещё короткий вопрос, правда совсем не по теме, он довольно маленький, поэтому задам здесь )
Если требуется задать какой-то тип T шаблонного аргумента, при этом T уже заранее инициализирован предыдущим аргументом, например, каким-нибудь const T &, а тип второго аргумента хочется записать как T от 1-го типа, например:

template<typename T>
void test(T && pointRef, std::remove_const_t<std::remove_reference_t<T>> * pointPtr) {}

И здесь, если передадут какой-нибудь const int & в качестве первого аргумента, то второй будет выводиться просто как int и будет удобно на него навесить * например
ну то есть, как я понимаю, получив 1-й аргумент T, последующие аргументы (если они есть) будут выводитсья относительно 1-го, ну и собственно цель - получить "чистый" ранее выведенный T
Нет же ничего пагубного в таком подходе ?
P.S.: можно std::decay, но у него более широкий спектр, поэтому было выбрано, как в примере

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

floppa322, пагубное есть. Через такие конструкции ты выражаешь определенные ожидания от пользователя твоего шаблона. Даже если пользователь - ты сам.
Через подобные объявления ты создаешь контакт. Но кто следит за его выполнением? Тут ведь нет ни одного ограничения. В иной ситуации тебе в test первым параметром зайдет внезапно prvalue, для которого T выведется в чистый тип. Трансляция даже не остановится, т.к. std::remove_reference и std::remove_const созданы так, чтобы не замечать отсутствия того, что они призваны удалять.
И в какой-то неожиданной ситуации это все, в конечном итоге, однажды рухнет.

Честно, проще взять второй шаблонный параметр, а в теле функции уже сделать static_assert на соответствие типов. И в этом месте яб именно std::decay использовал. Так твой контракт получит механизм соблюдения.
В C++20 так и вовсе можно использовать requires для явного определения контракта.

[floppa322]

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

В иной ситуации тебе в test первым параметром зайдет внезапно prvalue, для которого T будет чистым типом. Трансляция даже не остановится, т.к. std::remove_reference и std::remove_const созданы так, чтобы не замечать отсутствия того, что они призваны удалять.

А разве в случае prvalue трейты std::remove_reference+std::remove_const не сделают ничего ? Ну то есть был какой-то T, который в свою очередь prvalue, ну а std::remove_reference+std::remove_const из него сделают T, то есть - ничего ? Или я что-то не учитываю

в этом месте яб именно std::decay использовал

меня смущает, что decay может сделать array-to-pointer

[floppa322]

Евгений Шатунов, тут вот написано, что если T это не массив и не тип функции, то decay работает как
в примере выше, можно тогда заменить std::remove_const_t<std::remove_reference_t<T>> на std::remove_cv<std::remove_reference<T>> чтобы ещё volatile учитывался

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

floppa322,

А разве в случае prvalue трейты std::remove_reference+std::remove_const не сделают ничего ?

Об этом я и написал. Они ничего и не сделают. Даже не отмаркируют фактическое нарушение контракта (нужна константность, нужна ссылка). Т.е. может быть сейчас они и сделают что-то что тебе нужно, но так будет не всегда, за то они всегда будут позволять трансляцию дальше. В этом плане std::decay даже понятнее, т.к. его семантика говорит снять все что есть. А если ничего нет, то и снимать нечего. Тут нужно видеть разницу между "снять все что есть" и "снять именно это".

std::decay удобен своей семантикой. Читаешь и сразу понимаешь что происходит с переданным типом.
Связку из двух-трех трейтов в одной строке читать уже сложнее. Пусть эта связка и является прямой заменой std::decay. Преобразование к указателю - незначительное зло, с которым даже можно успешно жить.
На деле мне ни разу не пришлось пересекать тип массива статической длины и std::decay, они всегда идут разными путями.

[floppa322]

Евгений Шатунов, ок, понял, спасибо за подробные ответы )

Answer 1

[code_panik]

"Если требуется работа с голой памятью", - в c++ обычно не работают с голой памятью (free store). Работают с объектами, у которых есть время жизни. Мы выделяем память посредством низкоуровневых функций, только чтобы потом в ней создавать живые объекты, например с помощью placement new.

В этом смысле подход "без использования векторов и прочего" не имеет совершенно никакого значения. Как руками мы выделяем память и создаем в ней объекты, так поступает и вектор. Но только вектор позволяет нам сохранить здоровыми несколько клеток головного мозга. Другие аргументы в соответствующем разделе super-faq по ключевому слову vector.

"например, какое-то апи требует тип T *" - vector<T>::data().

Идиоматичность кода подразумевает использование актуальных стандартных средств языка. Оба примера напоминают c++03. Если код плохо читаем как в первом примере, то имеет смысл поискать лучшие альтернативы. Если их нет, то завернуть код во что-нибудь удобочитаемое, вектор например. Про идиоматичную низкоуровневую работу с памятью можно почитать у Страуструпа в примере реализации вектора.

Вопрос оптимизации - отдельная тема. Оптимизация под конкретные нужды не обязана быть идиоматичной или в принципе соответствовать общим представлениям. Например, вместо хранения массива структур, мы можем создать и использовать отдельно массивы полей структур. Можете поискать информацию по data-oriented design.

Answer 2

[res2001]

Можно использовать std::malloc вместо new.
Если класс полиморфный, то можно предварительно вычислять max из размеров всех детей и использовать это значение для выделения массива. Список детей должен быть заранее известен.

Comments

[floppa322]

ну да, я это и хотел сказать в нижнем комменте

Answer 3

[Василий Банников]

А в чём проблема использовать вектор? Из вектора же можно получить указатель на начальную точку и выделить заранее нужное количество места.
А вот эта простыня с reinterpret_cast вообще не очевидная

Comments

[floppa322]

Хм, мб я что-то не понимаю, но если vector типа T, то его дейструктор вызовет деструкторы всех T, а затем деструктор участка памяти, а если T * не нужно освобождать ?

[floppa322]

Ну и плюс, если Point таки полиморфный, и SIZE очень большой, при этом размер наибольшего наследника сравнительно небольшой (например = 20 байт), то можно было бы уложить всех наследников в массиве, со смещением 20 и итерироваться, должно быть намного быстрее
Хотя это уже к теме слишком косвенно относится )

[floppa322]

Вообще, откуда родился такой вопрос, смотрел на днях код UE4, они там как раз именно так и делали, как в первом примере

[Василий Банников]

floppa322, этот нюанс не учёл.

[code_panik]

floppa322, и эффект от оптимизаций пропадет, когда поменяются структуры классов или наследования? И если размеры наследников являются взаимно простыми числами, например 3 и 5, то при каждом доступе руками считать смещение или хранить по наименьшему общему кратному смещению?

[floppa322]

code_panik, да, забыл упомянтуь, самим объектам ещё нужно будет указать максимальное среди наследников выравнивание через alignas()

[floppa322]

code_panik, а, нет даже не всем объектам, а только самому большому нужно указать самое большое выравнивание

[code_panik]

floppa322, я не внимательно отнесся к вопросу. Вы правы, достаточно выбрать большее выравнивание, потому что даже в упакованном виде выравнивание будет степенью двойки, и вопрос о нечетном выравнивании не имеет смысла.