В вышедшей на днях новой версии статического анализатора кода PVS-Studio 5.10 появилась маленькая незаметная утилита PVS-Studio Standalone. Как говорится, маленький шаг для человечества и большой шаг для PVS-Studio :). Эта утилита уже сейчас позволяет делать (пока) две вещи:

• Просматривать без запуска Visual Studio IDE результаты анализа (.plog-файл), сохраненные на другой машине.
• Анализировать уже препроцессированные файлы (полученные каким-либо образом) без запуска препроцессора и без файлов проекта или makefile-ов.

При этом поддерживается полная навигация по коду, все настройки PVS-Studio, а также табличное представление результатов анализа, про которое я писал ранее. Это табличное представление позволяет использовать полный набор фильтров и сортировок диагностик с тем, чтобы максимально удобно работать с большим количеством сообщений.

В этой статье я покажу два сценария полезного использования этой утилиты.

Довольно часто, когда мы пишем статьи про статический анализатор C++ кода PVS-Studio, нам задают один из следующих вопросов:

1. А чем PVS-Studio лучше, чем Clang?
2. А вот Clang бесплатный, а вы стоите денег – не понятно, почему?
3. Clang лучше, туда легко можно добавить свои диагностики, ведь это open source!
4. Вам пора закрываться, Clang вас раздавит, если не сейчас, то когда отладят версию под Windows.(ну это даже и не как вопрос сформулировано).

Пришло время обстоятельно ответить на эти вопросы.

Если вы зайдете на страницу покупки PVS-Studio, то увидите, что мы убрали цену и предлагаем связаться с нами, чтобы обсудить её в индивидуальном порядке. Пока это эксперимент, результат которого мы не можем прогнозировать. Исчезновение цены не обозначает её рост. Наоборот, мы хотим предлагать PVS-Studio, в том числе и по более низкой цене, для небольших команд. Если вам интересно, как изменялись цены и, почему мы хотим опробовать такую модель продаж, то желаю приятного чтения. Думаю, те, кто занимается не только разработкой, но и продажами своих продуктов, найдёт в статье что-то интересное для себя.

Меня не покидает когнитивный диссонанс. На форумах обсуждаются возвышенные идеи о написании сверх надежных классов, кто-то рассказывает, что его проект собирается с ключами -Wall -Wextra -pedantic -Weffc++. Господи, где все эти достижения науки и техники? Почему я вижу кругом глупейшие ошибки? Может быть, со мной что-то не так?

После горячих обсуждений про "Большой Калькулятор", мне захотелось проверить ещё что-то из проектов, связанных с проведением исследований. Первое что нашлось, оказался открытый проект OpenMS, связанный с protein mass spectrometry. Этот проект оказалось написан с серьёзным подходом. При разработке используется как минимум Cppcheck. Так что ничего сенсационного ждать не приходилось. Однако был интерес, какие ошибки сможет найти PVS-Studio после Cppcheck. Заинтересовавшихся приглашаю продолжить чтение статьи.

Я хочу посвятить эту статью проблеме, о которой мало кто задумывается. Все шире и шире применяется моделирование различных процессов с помощью компьютера. Это замечательно, возможностью экономить время и материалы на бессмысленные химические, биологические, физические и прочие эксперименты. Обдув модели крыла на компьютере может в несколько раз сократить количество макетов, которое затем будет испытываться в реальной аэродинамической трубе. Численным экспериментам доверяют всё больше. Однако за торжеством численного моделирования никто не обращает внимания на рост сложности программ. В компьютере и к программам видят всего лишь инструмент для получения результата. Меня тревожит, что далеко не все знают и задумываются о том, что рост размера программы ведет к нелинейному росту числа ошибок. Опасно применять компьютер как просто большой калькулятор. Я и думаю, надо доносить эту мысль до других людей.

Аннотация

Около года назад мы опубликовали в блоге цикл статей о разработке плагинов для Visual Studio на языке C#. Сейчас мы переработали эти материалы, добавили новые разделы и предлагаем вашему вниманию новый вариант руководства.

После публикации статьи "Заземлённые указатели", к ней было сделано немало комментариев. В том числе было отмечено, что различные устройства часто поставляются с поразительно некачественным вспомогательным программным обеспечением. Иногда это весьма раздражает. Впрочем, я не собираюсь брюзжать. Я хочу рассказать забавную историю на эту тему.

Не так давно, один из сотрудников покинул наш коллектив и присоединился к компании, занимающийся разработкой программного обеспечения, связанного с встраиваемыми системами. Ничего особенного в этом нет, всегда и везде, кто-то уходит, а кто-то приходит. Всё зависит от количества плюшек, удобства и предпочтений. Интересно другое. Человек искренне переживает за состояние кода на новом месте работы, что в результате и вылилось в эту совместную статью. Тяжело, «просто программировать», когда знаешь, что такое статический анализ кода.

Мы, разработчики анализатора кода PVS-Studio, следим за тем, как более опытные заграничные компании продают свои решения. Про какие-то подходы к продажам мы знаем наверняка, о каких-то можем лишь догадываться. Что-то пытаемся перенять у них, а что-то перенять не можем.

Например, помимо стандартных групп диагностик вроде General Analysis, 64-bit analysis или Optimization у нас в PVS-Studio есть группа под названием Customer's Specific. Туда попадают диагностики, которые нужны нашим клиентам, но которые не подходят под прочие группы диагностик. Выражаясь более художественно можно сказать так. Группа диагностик Customer's Specific является эрогенной зонной нашего продукта. Если ее потрогать (добавить туда какую-то диагностику), то клиенту станет очень приятно. Естественно такой подход к развитию продукта и продаже надо применять очень осторожно, так как конечный клиент не обладает полным видением продукта и не имеет представления о том, куда продукт развивается.

Еще нам нравится, как работает предпродажная команда в компании Coverity. Мы конечно не уверены в этом на 100%, но нам кажется, что они работают примерно так. Если появляется потенциальный клиент, то к нему вылетает спецназ на вертолете, который на месте настраивает окружение, запускает анализатор, внимательно работает со списком диагностических сообщений и т.п. В завершении всего этого для потенциального клиента делается ПРЕЗЕНТАЦИЯ (!), в которой клиенту рассказывают про ошибки, найденные в его проекте, и говорят, что нужно делать, чтобы их не было (купить инструмент, ага). Почему они так делают? Хороший вопрос! Наверное, они считают, что разработчик инструмента может намного более качественно им пользоваться. У него больше опыта, он легче определяет ложные срабатывания и умеет их отсеивать, у него набит глаз на реальные ошибки и он их не пропустит. Это значит, что потенциальные клиенты получат намного больше ярких впечатлений от первого знакомства с продуктом, чем если бы они сами потыкали в нём кнопки.

И мы подумали – а что если нам действовать также как Coverity? К сожалению, спецназ на вертолете мы пока выслать не можем. Но что если мы попробуем проверить код потенциальных клиентов и сами найдем реальные программные ошибки в их проектах? Да еще и сделаем презентацию ну или хотя бы отчет о найденных проблемах? Наверняка тогда больше потенциальных пользователей захочет купить наш инструмент! Но, естественно, никто нам чужой код на сторону не даст, поэтому решили попробовать проверять код потенциальных клиентов в удаленном режиме, подключаясь к их компьютерам из своего офиса. Кому такое интересно – читаем далее.

Мы уже давно хотели проверить библиотеку Boost. У нас не было уверенности, что результатов проверки хватит на статью. Однако, желание не пропадало. Два раза мы пытались сделать это, но отступали, не разобравшись, как заменить вызов компилятора на вызов PVS-Studio.exe. Теперь мы вооружились новым инструментарием, и третья попытка оказалась удачной. Итак, возможно ли найти в Boost ошибки?

Мы давно не проверяли игры с помощью PVS-Studio. Решили это исправить и выбрали проект MTA. Multi Theft Auto (MTA) является модификацией для PC версий игры Grand Theft Auto: San Andreas от Rockstar North. MTA позволяет игрокам со всего мира играть друг против друга в режиме онлайн. Как написано в Wikipedia, особенностью игры является «оптимизированный код с наименьшим количеством сбоев». Что же, давайте посмотрим, что скажет анализатор кода.

Браузер Chromium очень быстро развивается. Например, когда в 2011 году мы впервые проверили этот проект (solution), он состоял из 473 проектов. Сейчас, он состоит уже из 1169 проектов. Нам было интересно, смогли ли разработчики Google сохранить высочайшее качество кода, при такой скорости развития Chromium. Да, смогли.

Время от времени мы рассказываем о своих внутренних исследованиях и разработках, которые происходят в команде разработчиков статического анализатора кода PVS-Studio для C/C++. Сегодняшняя история об очередной новинке, которую мы готовим в рамках нашего продукта.

Тем, кто следит за нашим проектом (а тем более пользуется им) известно, что наш анализатор изначально был плагином только для Visual Studio. Затем стало возможно пользоваться им как консольным приложением, встраиваемым в Makefile (спросите меня как, если не знаете). Потом, в начале этого года у нас появилась интеграция в C++Builder. Кстати у нас пока довольно мало пользователей под C++Builder, и мы не совсем понимаем почему. И вот недавно мы задумались над так называемым standalone приложением.

В этот раз я хочу поговорить о виртуальном наследовании в языке Си++, и почему его следует использовать очень осторожно. Предыдущие статьи: часть N1, N2, N3.
Статья написана по мотивам заметки "Грабли 2: Виртуальное наследование". Статья хорошая, но, на мой взгляд, несколько размыта, и новичок может не до конца уловить суть опасностей. Я решил предложить свой вариант описания проблем связанных с виртуальным наследованиям.

Программисты допускают невероятное количество опечаток, простых логических ляпов и делают ошибки благодаря Copy-Paste. Приглашаю отпробовать их. Приятного аппетита.

Программисты часто думают, что ошибки, отнимающие больше всего времени очень сложные и коварные. А простые ошибки они не делают.

Мы отправили разработчикам TortoiseSVN на некоторое время бесплатный ключ для анализатора PVS-Studio. Пока они не успели им воспользоваться, я решил быстро скачать исходные коды TortoiseSVN и самостоятельно выполнить анализ. Цель понятна. Очередная небольшая статья для рекламы PVS-Studio.

Мы проверили заголовочные файлы, входящие в состав Embarcadero C++Builder XE3. Фактически, это означает только проверку небольшого числа inline-функций. Соответственно найдено совсем немного подозрительных мест, но достаточно для небольшой заметки.

Приглашаю Си/Си++ программистов присоединиться к блогу PVS-Studio. Вы узнаете о разных интересных вещах из мира Си/Си++ и о том, кто, где и как программирует. Расскажу немного о том, что не было опубликовано на Хабре за время нашего отсутствия здесь.

Одной из методик выявления ошибок в программах является статический анализ кода. Мы рады, что это методология становится всё более популярной. Во многом этому способствует Visual Studio, в которой статический анализ является одной из многих функциональных возможностей. Эту функциональность легко попробовать и начать регулярно использовать. Когда человек понимает, что ему нравится статический анализ кода, мы рады предложить ему профессиональный анализатор PVS-Studio для языков Си/Си++/Си++11.