Евгений

Например:
https://www.browserling.com/internet-explorer-testing
https://www.browserstack.com/test-in-internet-explorer

https://developer.microsoft.com/en-us/microsoft-ed...

Но остаётся вопрос — зачем?

Если цель сделать коммерческую игру в разумные сроки то лучше не изобретать велосипед и все же использовать готовые движки - Unity(c#) или Unreal(C++). Если цель сделать игру, но при этом еще и "поиграться", то можно спустится на уровень ниже и собрать ее из компонентов типа (Ogre3D для графики, bullet/box2d/physx/havoc для физики, openal для звука и т.д.). Ну а если хочется совсем хардкора - вам сразу на уровень графических API: directX, openGL, vulkan. Последний самый перспективный, так как новый и кроссплатформенный.

Например
1. отключаешь display manager - lightdm (или что у тебя там для меню авторизации и выбора DE)
2. минимум что необходимо для работы графического режима - это xserver, для его запуска достаточно запустить утилиту X (кстати кажется до сих пор требует root), будет запущен графический сервер без Desktop Environment, но нужно понимать что DE отвечает за управление окнами, а точнее управление их размерами, положением на экране и вообще сокрытие/минимизация. Т.е. без этого, если твое приложение ожидает что пользователь будет перемещать его окна (а это к примеру диалоговое окно открытия/сохранения файлов) то он уже это сделать не сможет, все окна будут без заголовков и бордюра для изменения их размеров.
И кстати, чтобы графическое приложение запустилось и отображалось на X нужно устанавливать переменную окружения DISPLAY, значение смотреть либо в конфиге X либо в логах (скорее всего будет что то типа :0, это имя сервера и номер xserver, запущенного на нем, напоминаю, что linux из коробки умеет multiseat)
3. чтобы появился хоть какой то интерфейс взаимодействия, нужно установить DE, из минималистичных, идеальных для kiosk mode - я бы рекомендовал awesome, в нем к примеру можно настроить чтобы все открываемые окна сразу разворачивались на весь экран.

Кстати со всеми xserver обычно идет древний дефолтный twm, настолько примитивный что даже смешно, но если бы при открытии любого окна он не требовал от пользователя указать расположение и размер, им можно было бы пользоваться (не удивлюсь если это настраивается но никогда этим вопросом не задавался).

Из минималистичных и вполне функциональных DE можно предложить еще какой-нибудь openbox, его можно настроить так чтобы вообще никаких 'пуск' и списка задач не было, а только иконки и приложение на весь экран. Но пользователь сможет добраться до редактирования меню и запустить любое приложение, т.е. это не для kiosk mode

Чтобы запустить xserver с DE автоматически можно либо настроить автозагрузку в lightdm (это правильно) либо просто запускать утилиту startx, которая смотрит в пользовательском каталоге .xinitrc и запускает DE от туда.

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

Собственно как запускать приложения автоматически при включении компьютера тоже вопрос очень интересный, способов много, минимум три могу предложить
* правильный - настроить службу и прописать ей зависимости и автозапуск,
* так же до сих пор есть устаревший способ настройки службы без зависимостей sysvinit - /etc/init.d
* ну еще есть /etc/rc.local

Есть Flamegraph-ы
https://www.brendangregg.com/FlameGraphs/memoryfla...
https://github.com/brendangregg/FlameGraph

Это простой способ поделить строку на подстроки.

inline std::vector<std::string_view> SplitString( std::string_view input_string, const char separator )
{
	std::vector<std::string_view> parts;

	size_t part_length = 0;
	while( ( part_length = input_string.find( separator ) ) != input_string.npos )
	{
		parts.emplace_back( input_string.data(), part_length );
		input_string.remove_prefix( part_length + 1 );
	}

	if( !input_string.empty() )
	{
		parts.push_back( std::move( input_string ) );
	}

	return parts;
}

Не выйдет. C++ статически типизирован, и это то, что позволяет ему работать быстро.
А зачем, собственно, это понадобилось? В конкретной ситуации можно что-нибудь придумать.
P.S. Если хочется "просто", стоит оставаться на Питоне :)

Компиляция немного замедлится (но ты этого не заметишь), а выполнение, конечно же, нет.
Порой без auto не обойтись (в шабонных функциях с decltype, со структурными привязками, с лямбдами...), но часто код просто короче и читаемее.

Да, в Python динамическая типизация (т.е. полный срач), а в C++ - нет. В С++ есть динамическое связывание (для виртуальных методов), есть RTTI, но это совсем разные вещи.

Питон работает медленно, потому что он не компилируемый, а интерпретируемый. Т.е. он каждый раз компилируется "на лету".