автор сидит в очень узкой нише и натягивает ее на C++ в целом

давайте возьмем кодовую базу Chrome

перепишем ее на новом универсальном ассемблере? перепишем на Python, чтобы выполнять на GPU?

неужели невозможно написать автоматический конвертор файлов одного ассемблера в другой?

ну это работает по разному

например, если внутри находится вектор, то ты можешь написать m->push_back(val) и оно будет работать именно так, как я и написал

Mutexed<int> m;

Print( *(m.LockPtr()) );   // read access

*(m.LockPtr()) += 1;       // read-write access

// scoped access
{
   auto p = m.LockPtr();
   Print(*p);
   *p += 1;
  // ...
}

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

зы. код скриншотами и #ifdef вокруг C++17 это какой-то ;№""@#

один из самых громких тайтлов последнего времени с ретро 3d графикой это Pseudoregalia

более того, ошибку можно "придумать" и услужливый болванчик будет несколько часов наугад пытаться ее исправить )

будет на новом

IFile это очень плохое имя, даже с учетом всех рассуждений в комментарии

и почему не используется отдельный namespace?

функции "прочитай и верни строку по значению" в стандартном API нет из соображений производительности, при работе в цикле данные вычитываются в "разогретую" и преалоцированную области памяти

обидно, потому что Ryujinx лучше совместим, но там беда с производительностью из-за того, что он написан под .NET
а еще под раздачу попала Citra (

комплексные числа есть в C++ (более того, язык позволяет вводить такого рода понятия самостоятельного, если чего-то такого нет в библиотеке языка)

NAG точно так же доступна для C++

эпоха одноядерных процессоров, которые в массе игр не могли выдывать 60 fps

«консоль» от Steam — не совсем консоль

Если не вылазить из игрового режима (а это возможно), то можно получить вполне себе консольный экспириенс.

4 года имел на хозяйстве Switch, но после приобретения Steam Deck он собирает пыль.
Как по мне, битву за портативность N проиграла вчистую. Сильно дохлое железо и масса других факторов в сравнении с решением от Valve.

Да, игры от N это лучшее, что есть в индустрии, но я предпочитаю играть в них в эмуляторе на ПК. Потому что в большинстве случаев это дает сильно лучший опыт.

Куча всего была в бусте сильно задолго до 13-го года.

Ну и плюсы тем и хороши, что очень многое можно написать самостоятельно без потери эффективности и выразительности.

ну не правда

https://github.com/Neargye/magic_enum

или купить гаджет от Masimo

а мы хотим мерять скорость сортировки или скорость кэша L3 и памяти?

а почему бы не добавить fmt и string в precompiled headers?

потому что у 3dfx был специальный хитрый "22 битный" вывод изображения на экран из фреймбуфера

до честных 32х бит он не дотягивал, но был сильно лучше типичного 16-ти битного режима конкурентов

можно погуглить и найти много матриалов по этому поводу, например

https://www.beyond3d.com/content/articles/59/

мой собственный опыт показывает, что писать хороший поддерживаемый низкоуровневый продолжительно работающий код на С++ не умеет примерно никто

Эмпирические наблюдения за существующими вокруг нас C++ приложениями опровергают ваш личный опыт. Поэтому ваш личный опыт это ваши личные тараканы.

И надо понимать, что помимо проблем в виде страшных UB, сущесвует масса других вещей: архитектура приложения, документирование, процессы на проекте, проблемы с производительностью, гавнокод, баги (в том числе баги, связанные с безопасностью), дурные дедлайны и т.д. и т.п. И рамках действительного большого и сложного проекта все эти факторы играют существенно большую роль, чем ужасные недостатки C++ в сравнении с Rust.