Если исключения обрабатывать не в месте вызова, а несколькими слоями выше, то кода будет меньше, а границы try шире. В случае очень низкой вероятности ошибки эксперименты показывают что исключения не такие уж и медленные.
Но даже в таком случае они делают время выполнения непредсказуемым, что может быть важно для real time приложений. Но, например, для молотилки чисел это может быть не критично, хотя тоже high performance.
Чем дольше оттягивать переход, тем больше кода который не использует новые идиоматические подходы, и больше кода который потенциально будет мешать переходу (хотя это уже маловероятно если не отставать на 9 лет)
Переходить на новый стандарт нужно как можно скорее. Это не значит что нужно использовать вообще все его новшества, но наверное в каждом стандарте есть вещи которые упрощают жизнь и имеют крайне низкое трение даже со стороны консервативных коллег.
Для поддержки семантики и подсветки как раз придумали Language Server Protocol. Сейчас даже почти любой редактор или имеет встроенную поддержку, или имеет плагин. Для большинства вещей в C++ работает отлично, возможно даже лучше чем для многих более простых языков. Поэтому поддержка со стороны IDE можно считать вопрос решенный.
auto также скрывает тип, но повсеместен в современном C++. Хотя может вы из секты людей, которые всегда явно пишет тип переменных?
Хороший алиас позволяет в первую очередь меньше читать. Если он ограничен областью видимости, то когнитивная нагрузка вполне вероятно будет меньше чем при его отсутствии.
Алиасы значительно упрощают рефакторинг и позволяют избежать багов. Обобщенный код без алиасов я даже представлять не хочу.
Если говорить про границы API то конечно лучше иметь сигнатуры со стандартными именами. Но в реализациях функций и классов не вижу проблемы при грамотно выбранных именах.
Проблема может возникнуть во время переходы от базы до менее очевидных вопросов. Оценить корректность ответа человек без знаний не всегда может, а LLM обычно не указывает насколько она уверена в ответе.
OnlyOffice довольно неплохо принимается сообществом, совместимость с MS одна из лучших. Сам использую его уже давно, даже когда у меня ещё были ПК с Windows.
Специальной она является на уровне ОС и возможно MMU (Memory Management Unit). В обычных архитектурах есть регистр через который традиционно передается указатель на стек, и инструкции (push , pop) которые взаимодействуют с этим регистром. Но сам стек может распологаться в произвольном месте, определяемом ОС. С точки зрения машинного кода программы обращение к стеку зачастую эквивалентно обращению к какому-то адресу (за исключением спец инстркуций). C и С++ как языки не знают о стеке и куче, это детали реализации. В C++ есть storage duration, и переменные с automatic storage duration обычно хранятся на стеке, но они могут храниться напрямую в регистрах или вообще не быть материализованы. К куче доступ так или иначе производится через вызов системной функции, (обычно malloc) который может быть внутри operator new, std::allocator и т.п. Не уверен что имел ввиду автор под "автоматически управляется процессором", но за исключением нескольких инструкций для процессора стек - обычная область памяти, состоянием стека управляет программа, а выделением и контролем - ОС.
Инструменты делают ровно то, что в них заложил ремесленник ими управляющий. Результат работы инструментов предсказуем и повторяем. Задача "как сделать" всегда решалась человеком.
Модальность - ключевая особенность [нео]вима, которая позволяет эргономично работать без мышки, без извращений с Ctrl+Shift. Есть новое поколение модальных редакторов которые ещё не обзавелись плагинами, но уже имеют аудиторию показывает что эргономичность важна, а расширяемость ценой возможностей по умолчанию подходит не всем.
С исключениями спорно сформулирован пункт.
Если исключения обрабатывать не в месте вызова, а несколькими слоями выше, то кода будет меньше, а границы try шире. В случае очень низкой вероятности ошибки эксперименты показывают что исключения не такие уж и медленные.
Но даже в таком случае они делают время выполнения непредсказуемым, что может быть важно для real time приложений. Но, например, для молотилки чисел это может быть не критично, хотя тоже high performance.
Не могу согласиться.
Чем дольше оттягивать переход, тем больше кода который не использует новые идиоматические подходы, и больше кода который потенциально будет мешать переходу (хотя это уже маловероятно если не отставать на 9 лет)
Переходить на новый стандарт нужно как можно скорее. Это не значит что нужно использовать вообще все его новшества, но наверное в каждом стандарте есть вещи которые упрощают жизнь и имеют крайне низкое трение даже со стороны консервативных коллег.
Для поддержки семантики и подсветки как раз придумали Language Server Protocol. Сейчас даже почти любой редактор или имеет встроенную поддержку, или имеет плагин. Для большинства вещей в C++ работает отлично, возможно даже лучше чем для многих более простых языков. Поэтому поддержка со стороны IDE можно считать вопрос решенный.
Очень уж у вас широкие выводы для таких специфичных условий. Как правильно ответил kuza2000 и нейлон у вас конкретный, и детали очень маленькие.
Попробуйте напечатать, например, коробочку средних размеров, очень вероятно что в описанных в статье условиях будут проблемы.
Расскажите про несуществование нуля частицам без массы)
Ну вроде как получить уб как раз не тривиально потому что сложно получить мутабельную ссылку пересекающуюся с другой ссылкой.
autoтакже скрывает тип, но повсеместен в современном C++. Хотя может вы из секты людей, которые всегда явно пишет тип переменных?Хороший алиас позволяет в первую очередь меньше читать. Если он ограничен областью видимости, то когнитивная нагрузка вполне вероятно будет меньше чем при его отсутствии.
Алиасы значительно упрощают рефакторинг и позволяют избежать багов. Обобщенный код без алиасов я даже представлять не хочу.
Если говорить про границы API то конечно лучше иметь сигнатуры со стандартными именами. Но в реализациях функций и классов не вижу проблемы при грамотно выбранных именах.
Чем функция не обьект с оператором вызова?
Это деталь реализации, сильно зависящая от языка.
Проблема может возникнуть во время переходы от базы до менее очевидных вопросов. Оценить корректность ответа человек без знаний не всегда может, а LLM обычно не указывает насколько она уверена в ответе.
Второму чат ещё и подскажет рецепт чеснока в масле)
nice nano разрабатывался как пин-совместимый с pro micro, если в конфиге укзан pro micro, ничего менять не надо.
Основная причина старой версии lua - это использование LuaJIT. Что также делает lua прекрасным выбором для плагинов.
OnlyOffice довольно неплохо принимается сообществом, совместимость с MS одна из лучших. Сам использую его уже давно, даже когда у меня ещё были ПК с Windows.
Специальной она является на уровне ОС и возможно MMU (Memory Management Unit).
В обычных архитектурах есть регистр через который традиционно передается указатель на стек, и инструкции (
push,pop) которые взаимодействуют с этим регистром. Но сам стек может распологаться в произвольном месте, определяемом ОС.С точки зрения машинного кода программы обращение к стеку зачастую эквивалентно обращению к какому-то адресу (за исключением спец инстркуций).
C и С++ как языки не знают о стеке и куче, это детали реализации. В C++ есть storage duration, и переменные с automatic storage duration обычно хранятся на стеке, но они могут храниться напрямую в регистрах или вообще не быть материализованы. К куче доступ так или иначе производится через вызов системной функции, (обычно malloc) который может быть внутри
operator new,std::allocatorи т.п.Не уверен что имел ввиду автор под "автоматически управляется процессором", но за исключением нескольких инструкций для процессора стек - обычная область памяти, состоянием стека управляет программа, а выделением и контролем - ОС.
Уже давно есть DAP ( debug adapter protocol) через который можно сделать удобный интерфейс для gdb и lldb. Используется в VSCode и прочих редакторах.
Успешно использую данный функционал для ежедневной отладки.
Инструменты делают ровно то, что в них заложил ремесленник ими управляющий. Результат работы инструментов предсказуем и повторяем. Задача "как сделать" всегда решалась человеком.
Довольно сильная разница если сравнивать с LLM.
Из поста на реддите - Kailh PG1316
Очень интересно было бы послушать про placement new, launder и лайфтаймы с точки зрения стандарта.
Казалось бы простая вещь: вызвать конструктор по адресу, но повсюду ждёт UB.
БПФ же как раз определен через рекурсию, реализовать его рекурсивно вовсе не сложно.
Я бы даже сказал что через рекурсию он понятнее, но это обсуждаемо.
Модальность - ключевая особенность [нео]вима, которая позволяет эргономично работать без мышки, без извращений с Ctrl+Shift. Есть новое поколение модальных редакторов которые ещё не обзавелись плагинами, но уже имеют аудиторию показывает что эргономичность важна, а расширяемость ценой возможностей по умолчанию подходит не всем.