Первая диагностика V801 на тему микрооптимизаций, которая была реализована в PVS-Studio, как раз про копирования больших объектов :)
Кстати, есть и обратная – V835 (обнаружена функция, которая принимает параметр по ссылке на константный объект, когда эффективнее это делать по копии).
P.S. Мы называем это "микрооптимизациями", по причине, что статический анализатор, как правило не знает, часто используется какой-то код или нет. Для настоящей оптимизации нужен профайлер. Иногда, впрочем, пользователи писали, что заметно улучшили производительность, просто исправив код, на который указывал PVS-Studio этими самыми диагностиками.
V669. Анализатор обнаружил, что аргумент передается в функцию по ссылке, но не модифицируется в теле функции. Это может свидетельствовать о наличии ошибки.
Вот мне делать больше нечего :) Наверняка найдутся какие-то компиляторы без такой диагностики. Например для embedded или просто старые, но ещё где-то используемые. Но речь про общий тренд. Компиляторы и анализаторы вытравили такие баги из кода в целом :)
Да, но нет :). Если хочется сделать хорошо, нужно учитывать разные паттерны и тонкости. В PVS-Studio в диагностике V559 есть с десяток исключений, когда ругаться не надо, что-бы не раздражать программистов. Например, всё хорошо, если написано:
В целом я согласен, что специализированные самописные классы могут быть эффективнее их стандартных аналогов. Однако, не надо быть прям категоричным в этом. Есть смысл оптимизировать узкие места по необходимости, а не сразу писать всё своё :). Во-первых, своё может получиться куда менее надёжным. Во-вторых, эффективность многих встроенных классов значительно выросла, и они куда эффективнее, чем 10-20 лет назад. См. личную историю на тему std::string здесь (Вредный совет N50. Не верь в эффективность std::string).
Не весь код можно не трогать. Статья о том, что статический анализ помогает начать рефакторинг. Анализатор даёт и повод и отправную точку для этого. А старый код он вот такой, да... У меня нет иллюзий на тему того, какой код скрывают недра реальных проектов :)
В этом классе есть виртуальные функции. Следовательно, предполагается, что от этого класса будут наследоваться другие классы. А раз так, то и деструктор следует объявить как виртуальный.
Продолжаем наслаждаться. DPDK: 100 больших и маленьких багов.
А вот и обещанная статья "Поиск ошибок в юнит-тестах".
Да
Но не покрыт :)
P.S. Про юнит-тесты в DPDK отдельная земетка скоро будет :)
Хм.. Место для подумать, спасибо.
Движок habr для кода умный там, где не надо :)
Он схлопывает две пустые строчки в одну, поэтому не удаётся показать лишнюю пустую строчку в коде, про которою идёт речь. Она здесь:
Как вариант можно у нас в блоге посмотреть статью, там как показан так, как надо.
Первая диагностика V801 на тему микрооптимизаций, которая была реализована в PVS-Studio, как раз про копирования больших объектов :)
Кстати, есть и обратная – V835 (обнаружена функция, которая принимает параметр по ссылке на константный объект, когда эффективнее это делать по копии).
P.S. Мы называем это "микрооптимизациями", по причине, что статический анализатор, как правило не знает, часто используется какой-то код или нет. Для настоящей оптимизации нужен профайлер. Иногда, впрочем, пользователи писали, что заметно улучшили производительность, просто исправив код, на который указывал PVS-Studio этими самыми диагностиками.
V669. Анализатор обнаружил, что аргумент передается в функцию по ссылке, но не модифицируется в теле функции. Это может свидетельствовать о наличии ошибки.
По разному бывает :) Про игнор вспомнилось - 1000 глаз, которые не хотят проверять код открытых проектов :)
Вот мне делать больше нечего :) Наверняка найдутся какие-то компиляторы без такой диагностики. Например для embedded или просто старые, но ещё где-то используемые. Но речь про общий тренд. Компиляторы и анализаторы вытравили такие баги из кода в целом :)
Ну на самом деле такие ошибки обычно не при сравнении с true/false, а с -1 и т.п. True/false это просто особенно ярко и красиво :)
Да, но нет :). Если хочется сделать хорошо, нужно учитывать разные паттерны и тонкости. В PVS-Studio в диагностике V559 есть с десяток исключений, когда ругаться не надо, что-бы не раздражать программистов. Например, всё хорошо, если написано:
В целом я согласен, что специализированные самописные классы могут быть эффективнее их стандартных аналогов. Однако, не надо быть прям категоричным в этом. Есть смысл оптимизировать узкие места по необходимости, а не сразу писать всё своё :). Во-первых, своё может получиться куда менее надёжным. Во-вторых, эффективность многих встроенных классов значительно выросла, и они куда эффективнее, чем 10-20 лет назад. См. личную историю на тему std::string здесь (Вредный совет N50. Не верь в эффективность std::string).
Да )
Заключительная теортическая: С++: освобождение ресурсов в деструкторах с использованием вспомогательных функции.
Вот ещё багов :)
Проверка игрового движка qdEngine, часть третья: дополнительная десятка багов
Проверка игрового движка qdEngine, часть третья: дополнительная десятка багов
Не весь код можно не трогать. Статья о том, что статический анализ помогает начать рефакторинг. Анализатор даёт и повод и отправную точку для этого. А старый код он вот такой, да... У меня нет иллюзий на тему того, какой код скрывают недра реальных проектов :)
Проверка игрового движка qdEngine, часть вторая: упрощение C++ кода
Почему?