Почему T * может работать ощутимо быстрее (~ на 25-30%) в качестве хранилища данных, чем std::byte *?

mayton2019, забыл, извиняюсь, только что дополнил и указал это )

Почему T * может работать ощутимо быстрее (~ на 25-30%) в качестве хранилища данных, чем std::byte *?

mayton2019, ну я и говорю, что скорость работы связана, скорее всего, с какими-то фичами компилятора, когда у него из-за наличия явно T *, а не std::byte *, есть больше информации и он может сделать какие-то оптимизации, и интересно какие именно ему нельзя сделать, имея std::byte *
Ну и, покопавшись в известных имплементациях, вроде EASTL, заметил, что всегда используется именно T *, значит какая-то причина есть на это

Почему T * может работать ощутимо быстрее (~ на 25-30%) в качестве хранилища данных, чем std::byte *?

mayton2019, ну я на 99% уверен, что проблема фундаментально связана с типами
Если нужно, могу привести бенчмарки, но они одинаковые
Мог в принципе и код самих структур данных привести, но мне кажется, его никто бы смотреть особо не стал, именно поэтмоу решил скинуть диффы перехода с std::byte * на T *

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

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

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

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

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

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

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

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

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

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

В иной ситуации тебе в 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

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

Евгений Шатунов, ещё короткий вопрос, правда совсем не по теме, он довольно маленький, поэтому задам здесь )
Если требуется задать какой-то тип 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, но у него более широкий спектр, поэтому было выбрано, как в примере

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Является ли одинаковой скорость 2-х фрагментов кода (доступ к элементу массива по индексу)?

jcmvbkbc, на случай, если есть какие-то исключительные случаи с темплейтами / различия в генерируемом коде разных компиляторов

Является ли одинаковой скорость 2-х фрагментов кода (доступ к элементу массива по индексу)?

В любом случае, такой уровень экономии на спичках имеет реальную ценность только после того, как все остальные способы оптимизации программы уже выполнены, потому что это недалеко от реализации на ассемблере и интринсинках.

Просто хотелось именно на структурах данных (не на остальном коде) попрактиковаться в таких микрооптимизациях + это добавит понимания