хабраиндекс
245,19
8 мая 2013 в 10:25

Единорог вновь готов к общению с Си++ программистами

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

Наш единорог почти год отсутствовал на Хабре и за это время наши поклонники могли пропустить много интересного. Ниже я приведу ссылки на материалы, заслуживающие наибольшего внимания.

С нашей компанией все хорошо. Грандиозных событий нет, но есть стабильное развитие. Мы сменили офис, поддержали C++Builder, добавили в PVS-Studio десятки новых диагностических правил.

Примечание для тех, кто с нами ещё не знаком. Мы — это компания «СиПроВер». Наш логотип — единорог. А PVS-Studio, статический анализатор, выявляющий ошибки в исходном коде приложений на языке C,C++,C++11,C++/CX.

А теперь рассказ о новых интересных и полезных материалах


Мы подготовили фундаментальный цикл статей о том, как на C# создавать модули расширений (плагины) для Visual Studio 2005-2012. Статьи основаны на личном опыте, который мы накопили, создавая PVS-Studio. Цикл состоит из следующих статей:
  1. Введение.
  2. Создание, отладка и развертывание пакетов расширения сред Microsoft Visual Studio 2005/2008/2010/2012.
  3. Объектная модель автоматизации Visual Studio. Интерфейсы EnvDTE.
  4. Команды Visual Studio.
  5. Инструментальные окна Visual Studio.
  6. Интеграция в настройки Visual Studio.
  7. Проектная модель Visual C++.

Опубликована база ошибок, обнаруженных нами в различных open-source проектах. Эта база может послужить уникальным материалом для размышлений о разработке стандартов кодирования, написания статей о правилах программирования и помочь в других исследованиях связанных с повышением надежности программного обеспечения.

Заметка, наделавшая шума среди озадаченных и озабоченных безопасностью. Причина — найденные ляпы в TOR. Статья: "Безопасность, безопасность! А вы её тестируете?".

Мне довелось пообщаться с Уолтером Брайтом, который является создателем языка D. В итоге мы решили написать небольшую статью-интервью: "Язык D спешит на помощь".

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

Из последнего ещё стоит упомянуть статью с провокационным названием "Почему драйверы для Windows 8 глючат". Это мы проверили примеры драйверов, предлагаемые компанией Microsoft.

В недавно выпущенной пятой версии PVS-Studio мы поддержали C++Builder. Так что теперь не только пользователи Microsoft Visual Studio, но и Embarcadero RAD Studio могут попробовать наш статический анализ.

Прочее разное:
  1. Как статический анализ дополняет TDD.
  2. А пишут ли ещё на Си++?
  3. Большой отчет о повторной проверке проекта ReactOS
  4. Использование PVS-Studio в очень больших проектах (интеграция с MSBuild)
  5. Статический анализ наиболее эффективен при регулярном использовании. И вот почему.

И наконец, скачивайте PVS-Studio и спрашивайте у нас всё-всё-всё про статический анализ кода.
+61
26958
138
Andrey2008 290,0 G+

Комментарии (46)

0
hell0w0rd #
А мне вот интересно, если код полностью покрывать тестами перед написанием — такие ошибки все еще будут существовать? Также статический анализ врятли обнаружит логическую ошибку, а тест — запросто.
+6
Andrey2008 #
Ответ на вопрос с примерами: "Как статический анализ дополняет TDD".
+6
easyman #
Будут.
Одно другому не мешает.
+1
Volfram #
Ага, тогда такие ошибки переползут из кода приложения в код тестов :)
Тесты должны дополнять систему типов, там, где она не способна справиться, а не заменять её.
+3
olekl #
Да уж, количество и качество багов в примерах драйверов впечатляет!
+2
vershov #
Приятно что Вы начали охватывать новые IDE. Можно ли ожидать в дальнейшем поддержку Linux/Eclipse?
0
Andrey2008 #
Мы относительно близки к этому. Например, мы экспериментировали с Wine. Заметка на эту тему: Запуск PVS-Studio на Linux возможен? Направление это не развивается больше по экономическим соображениям, чем по техническим. А вообще, мы постоянно развиваемся и со временем охватим что-то ещё. Например, мы незаметно поддержали проверку проектов на языке C++/CX (Windows Phone 8 и Windows Store проекты в Visual Studio 2012).
0
vershov #
А можно подробнее про «экономику»?
По работе сталкивалсясь с STB устройствами и промышленными компьютерами с Линуксом на борту, для статических проверок использовал cppcheck и cpplint от google. PVS-Studio пришелся бы к столу.
+2
EvgeniyRyzhkov #
Экономика проста. (Количество усилий на Linux-версии) / (потенциальная отдача) = (не очень привлекательное число). Конечно же я могу быть не прав.
0
vershov #
Хочется услышать подробнее про «количество усилий» и как расчитываете потенциальную отдачу. Второе даже интереснее. Какие-то исследования проводились или решили на уровне «мне кажется не пойдет эта тема»?
0
EvgeniyRyzhkov #
На уровне «мне кажется».
+6
Andrey2008 #
Мы никогда не занимались настоящим исследованием этого вопроса, но есть четкое ощущение, что ничего хорошего из этого не выйдет. Я могу перечислить отдельные элементы, из которых складываются эти убеждения.

Мы были свидетелями мучений проекта, причиной которых являлось желание поддержать «парочку других платформ» без соответствующего увеличения штата сотрудников. Отчего-то программисты уверены, что поддержка других систем равнозначна возможности собрать проект другим компилятором на другой платформе. Это как раз, действительно, просто. Но абстрактная программа сама по себе никому не нужна. Нужно, чтобы она умела взаимодействовать с новым окружением, предоставлять адекватную для этой среды документацию, быть протестирована. Для неё должен быть создан дистрибутив и многое другое. В результате, работы надо проделать не чуть-чуть, а очень даже много. А потом всё это поддерживать. Думаю, поддержка каждой новой системы отнимает дополнительно увеличение штата (бюджета) на 10%-50%. Если этого не делать, то команда надорвётся.

Я уверен, что с анализатором кода, дополнительные затраты ресурсов будут велики. Сейчас мы не видим возможности быстро расширять штат. Таким образом, попытка поддержки новых платформ превратится в пшик. Просто не хватит сил сделать все хорошо. А плохо лучше и не делать.

Теперь про потенциальную пользу освоения, например, Eclipse. По отчету РУССОФТ процентное соотношение популярных инструментов разработки в 2012 году таково:
MS Visual Studio — 62%
Eclipse — 6 %

Конечно, привлечь ещё 6% программистов это замечательно. Но вот расходы при этом вырастут далеко не на 6%. Нужно будет разработать новый плагин. Без плагина консольная версия практически бесполезна. Нужно будет перерабатывать и расширять документацию. Потребуется создать новую базу open-source проектов, из которых построить соответствующую систему тестирования. И вообще всё это надо тестировать и поддерживать. Дистрибутив. Возможно, будут нюансы с распараллеливанием анализа. Альтернативная система хранения настроек (не реестр Windows). Ой, да много чего будет. Цена разработки PVS-Studio точно вырастет, более чем на 6%.

А теперь самое интересное. Потратив эти усилия, вовсе на значит, что продажи вырастут хотя бы на те же 6%. Linux/Open source сообщество очень неохотно приобретает лицензии. По крайней мере в плане инструментария. Они избалованы бесплатным программным обеспечением. И как результат, многие разработчики инструментария потихоньку сворачивают Linux версии. Я слышал о нескольких примерах, но уже забыл названия. Вспомнил только про «AQTime Linux Edition», которая теперь «AQtime Linux edition is no longer developed and supported». SmartBear Software как бы намекает нам…
+1
NickLion #
А C++ Builder какой процент? Просто мне кажется удивительным выбор данной среды. Я не знаю ни одного программиста, который бы использовал её.
0
Andrey2008 #
Не знаю. Причина поддержки C++Builder:

1. Это корпоративные пользователи, привыкшие покупать инструментарий.

2. Это было просто. Не потребовалось заново писать плагин. Подробнее: "Как мы разрабатывали версию PVS-Studio для Embarcadero RAD Studio".

0
NickLion #
Вот открыл их отчёт (стр. 74). То, что Вы привели — это данные за 2011 год. В 2012 MS VS уже 45%, а Eclipse — 16%.
0
Andrey2008 #
Да, я ошибся, 2011. Но даже эти числа не меняют кардинально ситуацию. Разные среды приходят и уходят, а VS остаётся. В 2009 году, например, Eclipse вообще имел 25%.
+2
NickLion #
Я же не говорил, что надо выбросить VS :) Я просто скорее вижу архитектуру так:
1. Не GUI утилита для проверки кода. Так понимаю, что это уже есть.
2. Библиотека с открытым API для получения списка ошибок и т.п.
3. Плагин-обёртка для п.2 для VS/C++Builder и др.

Т.е. даже если оригинально не будет предоставляться плагина для других сред, то открытый API позволит другим дописать и интегрировать в свой любимый инструмент (Qt Creator для меня, например). Или даже создание отдельного инструмента не привязанного к какой-либо IDE.

Понятно, что я оцениваю не понимая внутренностей работы, и возможно всё не так просто.
0
Andrey2008 #
На уровне идеи красиво. На практике, это никто не будет делать.

Представьте, приходит к начальнику сотрудник. И говорит, а давайте купим PVS-Studio за NNNN евро. Но только к нему нету плагина для нашей любимой среды разработки. Я и мой коллега разработаем его, поэтому на пол годика отвлечемся от основного проекта. Вот подпишите. Вопрос, как быстро и далеко сотрудник будет отравлен? :)

Это бы возможно сработало, начни мы раздавать продукт этим энтузиастам бесплатно. Но какая нам от этого польза? Никакой. Зато будет больше работы. (Только не надо говорить, что это повысит узнаваемость бренда и дела у вас как попрут вдруг :).
0
NickLion #
Бывает по-всякому. Допустим, в том же Google сотрудники имеют время для личных проектов. Но это скорее исключение. Так что, к сожалению, скорее соглашусь.
+2
EvgeniyRyzhkov #
Люди «не дочитывают» до конца корпоративные правила, где написано про личные проекты, которые: а) на технологиях google, б) являются собственностью google. Вот такие вот личные проекты…
+2
Paull #
Отвечу Вам как разработчик плагина: всё ещё проще ) Вы уже сейчас можете интегрировать анализатор в любую IDE, никакой библиотеки с открытым API для этого не нужно.

Сам анализатор — command line утилита, очень похожая по работе на компилятор, интегрировать её в любую IDE не сложнее интеграции компилятора, даже проще, т. к. от файлов требуется только компилябильность, без линковки. И не важно, через плагин это делать или напрямую через сборочную систему (make например).

Для запуска анализатора нужно передать ему параметры компиляции самого файла, плюс несколько дополнительных настроек. На выходе — plain text лог в stdout, одна строка — одно сообщение, всё предельно просто и понятно.

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

И главное, всё это давно описано в документации на нашем сайте. Но за несколько лет, что она там лежит, никто почему-то так и не изъявил желания сделать плагин под свою любимую IDE )
+1
NickLion #
Хм, тогда очень хорошо! Я просто думал, что на выходе файл внутреннего формата. Спасибо, приму к сведению.
0
Amomum #
Интересно было бы сравнить бесплатные статические анализаторы (cppcheck, codan) и PVS-studio. Хотя как codan давится шаблонами я уже насмотрелся :)
+3
Andrey2008 #
Сравнение Cppcheck и PVS-Studio. И с тех пор, мы стали ещё намного лучше. :)
+1
Amomum #
О, спасибо.
0
Andrey2008 #
0
Andrey2008 #
На тему PVS-Studio Standalone и Linux, возможно будет интересна вот эта новая заметка — "PVS-Studio теперь работает и без среды Visual Studio или C++Builder – проверяем препроцессированные файлы от чего угодно".
+5
dukei #
А почему единорог на логотипе блюет? Его воротит от ошибок?
+1
EvgeniyRyzhkov #
Bingo!
+9
Andrey2008 #
Мы маленькие, и логотип такого вида
image
вряд ли запомнят. А единорога запоминают. :)
Да, ему неприятны ошибки к коде.
0
turboNOMAD #
Ваш инструмент работает только с парой узкораспространенных IDE и их диалектами языка?
А как насчет нормального С++, соответствующего Стандарту? Как насчет самых популярных компиляторов — GCC и Clang? Есть ли интеграция в CMake/QMake?
+4
EvgeniyRyzhkov #
  • со стандартом — все ок;
  • с gcc — ok, все работает с mingw;
  • интеграция с make — ok, все есть.
+1
turboNOMAD #
Спасибо, стоит ознакомиться.

Интересно, подружится ли анализатор с Android NDK…
–4
turboNOMAD #
Не подружился.
На сайте обнаружен только какой-то *.exe для Windows. Ни пакетов для Linux, ни исходников нет.
Фтопку.
+2
EvgeniyRyzhkov #
Для MinGW ни пакеты для Linux, ни исходники не нужны.
–4
turboNOMAD #
Скорее, сам MinGW и Windows-only поделия не нужны.
+1
Andriyan #
А есть планы по созданию подобного инструмента для C#?
0
EvgeniyRyzhkov #
Нет.
+3
dordzhiev #
Ставьте решарпер. Все же в шарпе сложнее отстрелить себе ногу, реалтайма анализа хватает за глаза.
+1
DmitryO #
И снова здравствуйте, Андрей! Честно, я ждал когда вы вернетесь на Хабр. Жаль, что это заняло целый год.

Удачных постов!
0
Andrey2008 #
Спасибо. Постараюсь. :)
0
Juster #
Интересно, а ошибки в TOR и OpenSSL уже исправили? А в других opensource проектах?
0
Andrey2008 #
Можно скачать и посмотреть. Я не смотрел. Думаю, скорее всего да. По крайней мере, из TOR мне написали про спасибо.
0
Krovosos #
Наймите профессионала для перевода сообщений вашей программы. Русский английский ужасен.
0
EvgeniyRyzhkov #
Хотелось бы конкретики.
+2
Krovosos #
V521. Such expressions using the ',' operator are dangerous. Make sure the expression is correct

Это просто перевод русских слов на английский. Уверен, что слово dangerous англичанин здесь никогда бы не употребил. Faulty, error-prone.

Не являюсь профессионалом, но фразы режут слух.

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