Как стать автором
Обновить
4
0

Пользователь

Отправить сообщение

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

в реальном мире -- куча кейсов, когда компилятор не справляется

Гарантирует, что файл будет закрыт корректно. То, что при этом может возникнуть ошибка записи буфера, не означает, что файл не будет корректно закрыт. Смотрим сишную fclose -- даже если возникла ошибка, файл все равно будет корректно закрыт (т.е. об освобождении файла узнает ОС, file handle перестанет быть валидным).

Если вы хотите убедиться в том, что данные были успешно записаны, то логику вы должны строить, например, вокруг функции flush. Вокруг close ничего не построишь, это билет в один конец.

спасибо за интересный материал!

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

поставить условный телеграмм на сам дек

ну так он же работать будет только в десктоп режиме, не?

расскажи, как считать коллизию на GPU

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

Информация

В рейтинге
5 078-й
Откуда
Одесса, Одесская обл., Украина
Дата рождения
Зарегистрирован
Активность