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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Является ли хорошей практикой ввод приватного ключа через терминал на старте приложения(сервера), а не через файл?

Saboteur, ок, спасибо за информацию

Является ли хорошей практикой ввод приватного ключа через терминал на старте приложения(сервера), а не через файл?

Хорошо, спасибо за ответ

Ещё в голову пришла мысль: ведь даже с passphrase не выйдет сделать так, чтобы сервер (при острой надобности) рестартовал полностью автоматизированно ? Хотя, наверное, можно поднять 2 приложения: KeyStorage (довольно глупый демон, который (вероятнее всего) не может отвалиться и который будет раздавать ключи, правда тут тоже нужно будет продумать, чтобы атакующий не смог с ним взаимодействовать) ну и сам Целевой сервер, который на старте будет просить ключ у KeyStorage. Хотя с KeyStorage выглядит опасно, может быть, можно как-то через shared_memory сделать, чтобы, когда сервер рестартовал, у него был захардкожен указатель на память, где лежит ключ

Почему Clang (с -O3) не векторизует данный цикл?

mayton2019, хз странно, почему clang не справился, вроде бы очень прозрачный код для оптимизатора

Почему Clang (с -O3) не векторизует данный цикл?

mayton2019, ну да, gcc сделал это

0x0000555555559e78 <+88>:	movups %xmm1,(%rdx,%rax,1)
 0x0000555555559e7c <+92>:	movups %xmm0,(%rcx,%rax,1)

Почему Clang (с -O3) не векторизует данный цикл?

mayton2019, даже так не хочет

Word * words = new (std::align_val_t(16)) Word[N];
Half * halfs = new (std::align_val_t(16)) Half[N];

Почему Clang (с -O3) не векторизует данный цикл?

mayton2019, не векторизовал :(

Почему Clang (с -O3) не векторизует данный цикл?

Чтобы операцию можно было векторизовать, у тебя данные довольно строго должны укладываться в 128 бит. Желательно еще и выравнивание на 16 байт сделать.

Ну это понятно, просто было немного неясно, почему в 1-м случае он смог это сделать без выравнивания, а во втором нет.
Ниже дали разъяснение

Почему Clang (с -O3) не векторизует данный цикл?

Спасибо

Какие компиляторы "принято" использовать в клиентских приложениях для разных платформ (Windows, MacOS etc)?

Евгений Шатунов, ну просто я думал, что в каких-то предметных обастях или, может быть, даже не относительно предметной области и требований, а просто относительно платформы тот или иной компилятор является "стандартом" в 95% случаев
Просто, если всё протестировано, например, на clang'е, то ещё раз это делать, например, для MSVC не особо бы хотелось, если можно было бы обойтись одним компилятором )

Какие компиляторы "принято" использовать в клиентских приложениях для разных платформ (Windows, MacOS etc)?

Евгений Шатунов, например тут пишут

LLVM/Clang is the primary (or only) compiler for many gaming platforms these days. iOS, Android, PlayStation 4, MacOS/OSX, and Nintendo Switch all use Clang as their default native compiler.

XBox One is only supported by Microsoft's compiler, and their compiler is also still the most commonly used for Windows.

Поэтому-то у меня и возник такой вопрос )
Ну то есть, может быть, для real time приложений, критическим к задержке, MSVC будет более производительный код генерить для винды. Просто предположение

Интеграция C++ в Electron'е?

Если честно, даже не слышал про tauri
Спасибо, буду разбираться

Proof of work как защита от разного вида спама?

>>Неужели загрузка лишь одного ядра (а сейчас их в среднем 4-6) будет сочтена за майнер?
да, я не думаю что антивирус вообще будет смотреть на загрузку процессора
что же за магия там тогда

>Лучше рассчитывать именно из стоимости ресурсов, которые атакующий тратит на атаку и прибыли, которую он получает от атаки, чем выше сальдо - тем более вероятны атаки.
ну вот как раз благодаря PoW можно и сделать атаку невыгодной