Вообще не спорная. В статье это описано, но ещё раз:
Нет смысла говорить о подобных оптимизациях, если используются такие медленные операции как malloc/free. Если нужна скорость, нужно думать как сократить количество этих операций. Или, например, выделять небольшие буферы создавать на стеке. Или ещё что-то придумать, но точно не подобный if писать.
Оптимизирующие компиляторы сейчас хороши, и подобную штуку могут и без программиста провернуть. И даже лучше. Не надо лезть с такими микрооптимизациями, только захламляя код.
У нас сложная система публикации материала, включающая в себя собственный плагин для Word, конвертирующий специально оформленные документы в страницы сайта. Система предупреждает про неправильные написания терминов, названий проектов (свой словарь), символов (не используем табы в примерах кода), что в англоязычных материалах попали всякие русские (а, о), проверяющая корректность и доступность ссылок, размеры картинок (чтобы кто-то случайно не вставил фотку на 5 мегабайт) и ещё 100500 проверок. Можно сказать, что у нас ещё есть специализированный статический анализатор для документов :)
И мы точно не будем проталкивать во всю эту экосистему этот экзотический Unicode символ, чтобы один пример в одном квизе стал чуть лучше. Лучше наоборот разумно ограничивать возможности, поддерживаемы символы и т.д. В общем, комментарий не принимаю :)
Даже если обнаружила, это ничего не меняет. Ведь в коде то ошибки есть, а значит среда разработки не заменяет классические анализаторы кода, такие как PVS-Studio.
Они по разному используется. Задача среды - по возможности подсветить ошибки (пойдя на компромисс между глубиной анализа и скоростью).
Задача статического анализатора – провести глубокий анализ и предоставить гибкую многоуровневую систему контроля качества кода. Если разработчик не заметит/проигнорирует ошибку на этапе написания или закладке кода, то предупреждения будут разосланы, например после ночной проверки. В том числе, письмо с багами придёт тимлиду и он придёт к автору кода с наставлениями :) Это один из сценариев, возможны и другие.
Это не так работает. Никто никому ничего не всовывает :). Цель пообщаться с людьми, рассказать про продукт, ответить на вопросы. Но для этого, люди в начале должный подойти к стенду. Для этого нужна раздатка и другие способы привлечения. Люди неохотно подходят к пустым стендам. Описываемое - это просто первый шаг, чтобы начать общаться.
Согласен: у таких статей есть проблема однообразия. Мы стараемся как-то обыгрывать ошибки, экспериментируем с подачей материала и так далее. Но не всегда получается. С другой стороны, такие регулярные статьи про проверку проектов всё равно нужны.
Они вновь и вновь демонстрируют пользу анализаторов кода. Иначе возникнет ощущение, что проблема багов решена и тема анализаторов не актуальна. Мол компиляторы/среды разработки/AI-тулы и так всё уже находят. Или программисты наконец научились писать без ошибок :). Можно расслабиться :).
На самом деле ничего не меняется. По-прежнему нужны продвинутые инструменты анализа кода, дополняющие другие методологии борьбы с ошибками (обзоры кода, динамический анализ, юнит-тесты и так далее). Способ убедительно это продемонстрировать – найти ошибки в проекте. Поэтому писали, пишем и будем писать про найденные баги :)
Please, open merge requests or specific issues, instead of pointing to a blog post.
Надеюсь, найдётся желающий всё это сделать. Я считаю свою часть работы сделанной. У меня нет ресурсов заниматься по отдельности с каждым багом в каждом проверяемом проекте :(
Вообще не спорная. В статье это описано, но ещё раз:
Нет смысла говорить о подобных оптимизациях, если используются такие медленные операции как
malloc/free. Если нужна скорость, нужно думать как сократить количество этих операций. Или, например, выделять небольшие буферы создавать на стеке. Или ещё что-то придумать, но точно не подобныйifписать.Оптимизирующие компиляторы сейчас хороши, и подобную штуку могут и без программиста провернуть. И даже лучше. Не надо лезть с такими микрооптимизациями, только захламляя код.
Эстафета: Топ-10 ошибок, найденных в C#-проектах за 2023 год.
Для тех, кому нравятся разные наши задачки: Квиз со звёздочкой для С++ программистов от Сергея Кушниренко.
У нас сложная система публикации материала, включающая в себя собственный плагин для Word, конвертирующий специально оформленные документы в страницы сайта. Система предупреждает про неправильные написания терминов, названий проектов (свой словарь), символов (не используем табы в примерах кода), что в англоязычных материалах попали всякие русские (а, о), проверяющая корректность и доступность ссылок, размеры картинок (чтобы кто-то случайно не вставил фотку на 5 мегабайт) и ещё 100500 проверок. Можно сказать, что у нас ещё есть специализированный статический анализатор для документов :)
И мы точно не будем проталкивать во всю эту экосистему этот экзотический Unicode символ, чтобы один пример в одном квизе стал чуть лучше. Лучше наоборот разумно ограничивать возможности, поддерживаемы символы и т.д. В общем, комментарий не принимаю :)
Так просто подкину :)
Путеводитель C++ программиста по неопределенному поведению.
60 антипаттернов для С++ программиста.
Относитесь проще. Всё это носит развлекательный характер, а не, например, для проведения собеседований :)
Это ограничения сайта при публикации статьи. Не будьте так строги. :)
Не стоит предсказывать, как оно будет :)
Ложные представления программистов о неопределённом поведении.
Новая серия: Предновогоднее шоу: Топ 10 ошибок в C и С++ проектах в 2023 году.
Даже если обнаружила, это ничего не меняет. Ведь в коде то ошибки есть, а значит среда разработки не заменяет классические анализаторы кода, такие как PVS-Studio.
Они по разному используется. Задача среды - по возможности подсветить ошибки (пойдя на компромисс между глубиной анализа и скоростью).
Задача статического анализатора – провести глубокий анализ и предоставить гибкую многоуровневую систему контроля качества кода. Если разработчик не заметит/проигнорирует ошибку на этапе написания или закладке кода, то предупреждения будут разосланы, например после ночной проверки. В том числе, письмо с багами придёт тимлиду и он придёт к автору кода с наставлениями :) Это один из сценариев, возможны и другие.
Это не так работает. Никто никому ничего не всовывает :). Цель пообщаться с людьми, рассказать про продукт, ответить на вопросы. Но для этого, люди в начале должный подойти к стенду. Для этого нужна раздатка и другие способы привлечения. Люди неохотно подходят к пустым стендам. Описываемое - это просто первый шаг, чтобы начать общаться.
Согласен: у таких статей есть проблема однообразия. Мы стараемся как-то обыгрывать ошибки, экспериментируем с подачей материала и так далее. Но не всегда получается. С другой стороны, такие регулярные статьи про проверку проектов всё равно нужны.
Они вновь и вновь демонстрируют пользу анализаторов кода. Иначе возникнет ощущение, что проблема багов решена и тема анализаторов не актуальна. Мол компиляторы/среды разработки/AI-тулы и так всё уже находят. Или программисты наконец научились писать без ошибок :). Можно расслабиться :).
На самом деле ничего не меняется. По-прежнему нужны продвинутые инструменты анализа кода, дополняющие другие методологии борьбы с ошибками (обзоры кода, динамический анализ, юнит-тесты и так далее). Способ убедительно это продемонстрировать – найти ошибки в проекте. Поэтому писали, пишем и будем писать про найденные баги :)
Спасибо. Приятно слышать положительные отзывы о наших статьях в комментариях или на конференциях.
А теперь статья: Что нового в .NET 8?
Да, но нет.
Надеюсь, найдётся желающий всё это сделать. Я считаю свою часть работы сделанной. У меня нет ресурсов заниматься по отдельности с каждым багом в каждом проверяемом проекте :(
Часть попала из subprojects.
Продолжение темы Flipper Zero: зарождение идеи, вдохновение и отсылки, основной функционал, мировой успех, безопасность и ответственность, что нового.
Интервью с разработчиками мультитула для хакеров и пентестеров Flipper Zero.
Достаточно оперативно начали вносить правки. Молодцы. А то бывает, по пол года-год висят подобные issues. А то и по... :)
Теоретические