Что будет, если заинлайнить всё

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

Векторы в RISC-V на практике: вычисление softmax

Спасибо за напоминание, почему не надо писать на интринсиках:)

Полиморфизм, мета-программирование и космическая баллистика: 4 доклада о C++ и Linux Kernel

Смотрел, понравилось.

Управление зависимостями на C++ с помощью vcpkg registry и сервера кеширования

Главное, что бы это все в очередной раз не сломалось под своей тяжестью.

Спасибо конечно за информацию. Гуглить, гуглить и ещё раз гуглить.

Лаконичный макрос defer для C++17

Мне не нравится вариант с unique_ptr тем, что будет по крайней мере один new. Банальный пример, а уже лезем в память. Возможно, что как то все оптимизируется. Я не вникал, как оно там устроено. Если, что поправьте.

Лаконичный макрос defer для C++17

Ну и как предложили выше можно сделать нормальную обёртку конкретно для виндовых структур.

Это будет оптимальнее. Хотя желание автора тоже понятно. Некий стандартный универсальный механизм.

Лаконичный макрос defer для C++17

Примерно так, так как HANDLE используется чуть менее чем во всем WinAPI облегчит жизнь. Это общая идея. Таким образом типизировать другие типы. Добавить inline, но со сборкой O2 думаю и так компилятор догадается.

template <typename T>
class Handler
{
public:
	Handler(T handle) :
		_handle(handle)
	{
	}
	~Handler()
	{
		if (_handle != nullptr) CloseHandle(_handle);
	}

	T Get()
	{
		return _handle;
	}

	bool Ok()
	{
		return _handle != nullptr;
	}
private:
	T _handle;
};

Лаконичный макрос defer для C++17

Ещё вариант, без мам, пап и unique_ptr

bool MakeDumpToFile(DWORD pid, PCWCHAR filename)
{
	Library dbgdll("dbghelp.dll");
	if (!dbgdll.Ok()) return false;

	auto pfnMiniDumpWriteDump = (decltype(&MiniDumpWriteDump)) dbgdll.GetAddress("MiniDumpWriteDump");
	if (!pfnMiniDumpWriteDump) return false;
		
	Handler<HANDLE> proc(procOpenProcess(PROCESS_ALL_ACCESS, FALSE, pid));
	if (!proc.Ok()) return false;
			
	Handler<HANDLE> file(CreateFileW(filename, GENERIC_WRITE, NULL, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL));
	if (!file.Ok() && file.Get() == INVALID_HANDLE_VALUE) return false;
				
	bool result = pfnMiniDumpWriteDump(proc.Get(), pid, file.Get(), MiniDumpNormal, NULL, NULL, NULL);
	return result;
}

Лаконичный макрос defer для C++17

Придумал, ещё вариант по старинке:) Класс Library и Handler дергают деструктор FreeLibrary и CloseHandle.

bool MakeDumpToFile(DWORD pid, PCWCHAR filename)
{
	Library dbgdll("dbghelp.dll");
	if (dbgdll.Ok())
	{
		auto pfnMiniDumpWriteDump = (decltype(&MiniDumpWriteDump)) dbgdll.GetAddress("MiniDumpWriteDump");
		if (pfnMiniDumpWriteDump)
		{
			Handler<HANDLE> proc(procOpenProcess(PROCESS_ALL_ACCESS, FALSE, pid));
			if (proc.Ok())
			{
				Handler<HANDLE> file(CreateFileW(filename, GENERIC_WRITE, NULL, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL));
				if (file.Ok() && file.Get() != INVALID_HANDLE_VALUE)
				{
					bool result = pfnMiniDumpWriteDump(proc.Get(), pid, file.Get(), MiniDumpNormal, NULL, NULL, NULL);
					return result;
				}
			}
		}
	}

	return false;
}

Лаконичный макрос defer для C++17

Современные фичи С++ это хорошо, правильно. Но если уж исходить из юзабилити, вполне понятный вариант второй. Проверил, прочитал, закрыл. Никто же не мешает отделить LoadLibraryA и FreeLibrary в класс и дергать его в данном методе при выходе из функции сработает деструктор. Написать шаблон с HANDLE, который в деструкторе будет всегда CloseHandle(file) это делать.

Помню, вроде на rsdn подобный код был, типа заворачиваем WinApi в ООП с конструкторами и деструкторами.

bool MakeDumpToFile(DWORD pid, PCWCHAR filename)
{
	HMODULE dbgdll = LoadLibraryA("dbghelp.dll");
	if (dbgdll)
	{
		auto pfnMiniDumpWriteDump = (decltype(&MiniDumpWriteDump)) GetProcAddress(dbgdll, "MiniDumpWriteDump");
		if (pfnMiniDumpWriteDump)
		{
			HANDLE proc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
			if (proc)
			{
				HANDLE file = CreateFileW(filename, GENERIC_WRITE, NULL, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
				if (file && file != INVALID_HANDLE_VALUE)
				{
					bool result = pfnMiniDumpWriteDump(proc, pid, file, MiniDumpNormal, NULL, NULL, NULL);
					CloseHandle(file);
					return result;
				}
				CloseHandle(proc);
			}
		}
		FreeLibrary(dbgdll);
	}
	return false;
}

Мы наш, мы новый SDL3 построим или вперед в прошлое

Думаю будет меньше лагов со стороны Linux. Надо будет накатить и проверить. Данный ПК я использовал как медиацентр несколько лет, так как есть hdmi выход. И тогда стояла lubuntu 16.04, идеальная версия дистра на мой взгляд. Быстрый, все работает из коробки.

Сейчас возможно соврепеный linux, будет +- как windows 10. Надо будет затестить.

Мы наш, мы новый SDL3 построим или вперед в прошлое

Машинку пошто мучаешь? Поставь на неё ХР и есть актуальный порт Хромиума.

Это полумеры. Хочется пользоваться современным софтом на таком ПК. Хорошо, что есть альтернатива в виде Linux.

Windows Xp и Windows 98, стоит на Pentium 4, для нативной разработки и тестирования библиотеки. Правда смотрю не в очень аутентичный 27 дюймовый монитор с разрешением 1920x1080.

Мы наш, мы новый SDL3 построим или вперед в прошлое

Я знаю SDL, он мне нравится и он можно сказать стандарт. И я реализую лишь минимально используемую часть SDL3.

Мы наш, мы новый SDL3 построим или вперед в прошлое

У меня есть ПК Athlon II X4 640 + 8 гб ОЗУ. Для интернета ещё подходит, но уже видна задержка, долго грузит, парсит страницы. Windows 11 на нём скажем так не блещет. И вот как раз разговоры об этом, что не процессор устарел, а ПО стало более требовательным.

Ладно бы я на нём 4k софтово кодировал или дипсик локально запускал. Но я говорю, о довольно стандартном его использовании.

Мы наш, мы новый SDL3 построим или вперед в прошлое

Вы абсолютно правы. Но проблема даже не не в поддержке старых ОС. А уже железа недавнего прошлого. Когда тот же процессор i7-960, это уже печатная машинка. Современный софт, уже не может тянуть данный процессор. И я не говорю об играх ААА класса.

Мы наш, мы новый SDL3 построим или вперед в прошлое

Я так не утверждал, я писал, что С# не раскрыт, его хорошо бы применять не только для веба.

Мы наш, мы новый SDL3 построим или вперед в прошлое

Конечно же не Pentium 2:) Хотя бы процессоры 10-летней давности.

Мы наш, мы новый SDL3 построим или вперед в прошлое

Есть такое, скорее всего специфика использования языка C# влияет на это. Он был создан чик, чик и в прод. И с этим очень хорошо справляется. Хотя на мой взгляд, весь его потенциал не раскрыт. Он может не только в веб.

Ещё многое зависит от самого программиста, кому то не интересно выходить за границы NET. Это не плохо, просто так есть.

Возможно если бы я писал только на C# и не знал С++. Я бы просто не обращал на эту проблему, работает и работает. Конечно это мой интерес вне работы, желание что то улучшить по мере сил. Поддержка старых систем вряд ли может считаться улучшением, но у такого подхода есть хороший эффект. Если работает на железе 25+ лет, то на современном оно работает с меньшими затратами ЦПУ и ОЗУ. А это открывает возможность портировать под современные микроконтроллеры, которые уже давно обогнали десктопы на 486DX ЦПУ. И далее клубок разматывается.

А самое прекрасное, что в библиотеке нет ни строчки ассемблера, все написано высокоуровнево с использованием контейнеров и итераторов С++. Код быстрый, простой и высокоуровневый.

Мы наш, мы новый SDL3 построим или вперед в прошлое

Читал раннее на форумах, возможно RSDN. Что бы софт был быстрым, программисты должны разрабатывать софт на ПК прошлых поколений. Когда у тебя i7 и 100500 озу, нет никакого смысла, что то делать и так быстро работает. Типа у меня же не тормозит:)

Мы наш, мы новый SDL3 построим или вперед в прошлое

Историки копаются в античности и им это нравится. Вот и я так же. Поддержка Windows 98 по строчкам кода, почти ничего не стоит, поэтому лучше поддержать, чем не поддержать. Мне просто нравится копаться в старом железе, старых ОС, софте. Ну и главный эффект от этого всего это улучшение производительности вне зависимости от конкретной ОС или железа.