Много-много лет изучал английский по классическому "аналитическую" подходу. Получил нулевой результат в области speaking.
Потом пошел по тому пути, как учат язык дети -- слушаешь, повторяешь, отвечаешь. Каждый день тратил полтора-два часа, через полгода заговорил и до сих пор не могу остановиться )
Сейчас имею точно такой же опыт в области болгарского: аналитика против практики не имеет вообще никаких шансов.
Если нужно только понимать и говорить, то весь этот аналитический мусор просто пустая трата времени. Большинство детей идет в школу прекрасно разговаривая и понимая взрослых, вообще не парясь по поводу частей речи, времен, падежей и прочей шелухи. И такой метод изучения языка ОТЛИЧНО работает для взрослых, просто не надо слушать великих преподавателей, типа автора этой статьи, которые будут вас убеждать, что вы ничего не добьётесь, пока вам не вынесут мозг всей этой академической чушью, изучение которой вас никак не приближает к возможности общаться с другими людьми на новом языке.
IFile это очень плохое имя, даже с учетом всех рассуждений в комментарии
и почему не используется отдельный namespace?
функции "прочитай и верни строку по значению" в стандартном API нет из соображений производительности, при работе в цикле данные вычитываются в "разогретую" и преалоцированную области памяти
Если не вылазить из игрового режима (а это возможно), то можно получить вполне себе консольный экспириенс.
4 года имел на хозяйстве Switch, но после приобретения Steam Deck он собирает пыль. Как по мне, битву за портативность N проиграла вчистую. Сильно дохлое железо и масса других факторов в сравнении с решением от Valve.
Да, игры от N это лучшее, что есть в индустрии, но я предпочитаю играть в них в эмуляторе на ПК. Потому что в большинстве случаев это дает сильно лучший опыт.
мой собственный опыт показывает, что писать хороший поддерживаемый низкоуровневый продолжительно работающий код на С++ не умеет примерно никто
Эмпирические наблюдения за существующими вокруг нас C++ приложениями опровергают ваш личный опыт. Поэтому ваш личный опыт это ваши личные тараканы.
И надо понимать, что помимо проблем в виде страшных UB, сущесвует масса других вещей: архитектура приложения, документирование, процессы на проекте, проблемы с производительностью, гавнокод, баги (в том числе баги, связанные с безопасностью), дурные дедлайны и т.д. и т.п. И рамках действительного большого и сложного проекта все эти факторы играют существенно большую роль, чем ужасные недостатки C++ в сравнении с Rust.
Гарантирует, что файл будет закрыт корректно. То, что при этом может возникнуть ошибка записи буфера, не означает, что файл не будет корректно закрыт. Смотрим сишную fclose -- даже если возникла ошибка, файл все равно будет корректно закрыт (т.е. об освобождении файла узнает ОС, file handle перестанет быть валидным).
Если вы хотите убедиться в том, что данные были успешно записаны, то логику вы должны строить, например, вокруг функции flush. Вокруг close ничего не построишь, это билет в один конец.
один из самых громких тайтлов последнего времени с ретро 3d графикой это Pseudoregalia
зависит от целей
Много-много лет изучал английский по классическому "аналитическую" подходу. Получил нулевой результат в области speaking.
Потом пошел по тому пути, как учат язык дети -- слушаешь, повторяешь, отвечаешь. Каждый день тратил полтора-два часа, через полгода заговорил и до сих пор не могу остановиться )
Сейчас имею точно такой же опыт в области болгарского: аналитика против практики не имеет вообще никаких шансов.
Если нужно только понимать и говорить, то весь этот аналитический мусор просто пустая трата времени. Большинство детей идет в школу прекрасно разговаривая и понимая взрослых, вообще не парясь по поводу частей речи, времен, падежей и прочей шелухи.
И такой метод изучения языка ОТЛИЧНО работает для взрослых, просто не надо слушать великих преподавателей, типа автора этой статьи, которые будут вас убеждать, что вы ничего не добьётесь, пока вам не вынесут мозг всей этой академической чушью, изучение которой вас никак не приближает к возможности общаться с другими людьми на новом языке.
более того, ошибку можно "придумать" и услужливый болванчик будет несколько часов наугад пытаться ее исправить )
будет на новом
IFile это очень плохое имя, даже с учетом всех рассуждений в комментарии
и почему не используется отдельный namespace?
функции "прочитай и верни строку по значению" в стандартном API нет из соображений производительности, при работе в цикле данные вычитываются в "разогретую" и преалоцированную области памяти
обидно, потому что Ryujinx лучше совместим, но там беда с производительностью из-за того, что он написан под .NET
а еще под раздачу попала Citra (
комплексные числа есть в C++ (более того, язык позволяет вводить такого рода понятия самостоятельного, если чего-то такого нет в библиотеке языка)
NAG точно так же доступна для C++
эпоха одноядерных процессоров, которые в массе игр не могли выдывать 60 fps
Если не вылазить из игрового режима (а это возможно), то можно получить вполне себе консольный экспириенс.
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.
в идеальном мире хотелось бы, чтобы компиляторы были такими умными
в реальном мире -- куча кейсов, когда компилятор не справляется
Гарантирует, что файл будет закрыт корректно. То, что при этом может возникнуть ошибка записи буфера, не означает, что файл не будет корректно закрыт. Смотрим сишную fclose -- даже если возникла ошибка, файл все равно будет корректно закрыт (т.е. об освобождении файла узнает ОС, file handle перестанет быть валидным).
Если вы хотите убедиться в том, что данные были успешно записаны, то логику вы должны строить, например, вокруг функции flush. Вокруг close ничего не построишь, это билет в один конец.
спасибо за интересный материал!
дек рулит, decky loader рулит, но вот всплывающие уведомления, это последнее, что я хотел бы видеть, когда играю или, например, читаю книгу )