Комментарии 170
Спасибо. В ваших статьях всегда есть интересные куски кода, показывающие возможные проблемные места. Беру себе на заметку.
1 1 License information not found. Starting trial version. Only several errors are shown. TNLab 0 False
0 2 V003 Unrecognized error found: Cannot read safe type list from file c:\users\lynxy\appdata\roaming\pvs-studio\safe_types.txt TNLab ChangeTypeDlg.cpp 1 False
И так далее, все ошибки V003.
Использую MSVS2005, Win7x64. Указанного файла там действительно нет.
Видимо что-то не так с инсталлятором, поскольку установились файлы в профиль администратора (при запуске инсталлятора он потребовал админские права), а работаю то я под обычным юзером (чего и вам рекомендую =).
0 2 V003 Unrecognized error found: Cannot read safe type list from file c:\users\lynxy\appdata\roaming\pvs-studio\safe_types.txt TNLab ChangeTypeDlg.cpp 1 False
И так далее, все ошибки V003.
Использую MSVS2005, Win7x64. Указанного файла там действительно нет.
Видимо что-то не так с инсталлятором, поскольку установились файлы в профиль администратора (при запуске инсталлятора он потребовал админские права), а работаю то я под обычным юзером (чего и вам рекомендую =).
Для Вашего случая создайте пустой файл c:\users\lynxy\appdata\roaming\pvs-studio\safe_types.txt и ошибка пропадет. Описание проблемы в соседнем комменте (здесь)
1 1 License information not found. Starting trial version. Only several errors are shown. Chrome 0 False
0 2 V003 Unrecognized error found… Chrome init.cpp 1 False
и далее много сообщений V003
файл safe_types.txt есть
0 2 V003 Unrecognized error found… Chrome init.cpp 1 False
и далее много сообщений V003
файл safe_types.txt есть
Что-то пошло не так. Помогите разобраться. Прошу написать мне в почту karpov[@]viva64.com. Если возможно, сгенерируйте *.i файл, упакуйте и пришлите мне. Это можно сделать, установив в настройках «не удалять временные файлы».
Видимо по этой же причине под обычным пользователем в MSVS2010 не появился PVS-Studio. Что делать и кто виноват? =)
Это особенность интеграции в Visual Studio 2010. По-умолчанию PVS-Studio интегрируется в админовского пользователя. Если Вы хотите работать в VS2010 под обычным пользователем с Visual Studio, то надо вручную запустить файл «C:\Program Files (x86)\PVS-Studio\PVS-Studio-vs2010.vsix», который является инсталятором для VS2010. Он легко установится и все будет работать из под текущего пользователя.
Выглядит кривовато, согласны, но это меньшее из нескольких зол.
Выглядит кривовато, согласны, но это меньшее из нескольких зол.
А 'TRIAL RESTRICTION' — это так и должно быть? Уж очень много ошибок помечено таким образом.
Как я понимаю, вы смотрите на предупреждения, относящиеся к проверке 64-битных программ. Отожмите кнопку «64».
p.s. В статье описано как это сделать и даже картинка есть. :)
p.s. В статье описано как это сделать и даже картинка есть. :)
Ага, я что-то на слово «бесплатно» слишком радостно отреагировал. =)
Проанализировал несколько своих проектов: предупреждений нет. Либо я слишком правильно пишу код, либо наоборот слишком неправильно для статического анализа. =)
P.S. Больше тестировать не хочется, уж очень долго идёт анализ.
P.P.S. Понимаю, что анализ это не слишком частая операция, но ведь хочется проверить сразу на всём что есть. =)
Проанализировал несколько своих проектов: предупреждений нет. Либо я слишком правильно пишу код, либо наоборот слишком неправильно для статического анализа. =)
P.S. Больше тестировать не хочется, уж очень долго идёт анализ.
P.P.S. Понимаю, что анализ это не слишком частая операция, но ведь хочется проверить сразу на всём что есть. =)
>> уж очень долго идёт анализ.
Какая машина?
Какая машина?
OS: Win7x64, Mem: 4 ГБ, CPU: Intel® Core(TM)2 CPU 6420 @2.14GHz. Антивирусов и прочей фигни нет.
Солюшен из двух проектов, в одном 40 файлов, в другом 18. Общий размер исходных файлов (*.cpp + *.h) ~300 КБ. По моим меркам — мелочь (собирается за несколько секунд).
Анализ занял ~7 минут.
(Пока мерил заметил, что вызывается компилятор для препроцессинга, появляются файлы *.i =).
Солюшен из двух проектов, в одном 40 файлов, в другом 18. Общий размер исходных файлов (*.cpp + *.h) ~300 КБ. По моим меркам — мелочь (собирается за несколько секунд).
Анализ занял ~7 минут.
(Пока мерил заметил, что вызывается компилятор для препроцессинга, появляются файлы *.i =).
Ха, 7 минут… И ЭТО вы называете долго? Вот когда речь о часах идет, тогда уже приходится подсказывать, что какой-то код можно исключить из анализа, что-то еще где-то «донастроить». А 7 минут — это не долго.
У нас ОЧЕНЬ круто сделано распараллеливание. Всегда используются все ядра процессора автоматически (при желании можно использовать только часть, регулируется в настройках). Это позволяет на машине с четыремя ядрами иметь неплохую производительность. Большинство инструментов не поддерживают несколько ядер.
Так что тут рекомендация такая — ядер побольше и будет хорошо. Один наш клиент (пользователи Site License) купил продукт после того, как на его 16-ядерной машине мы стали на всех ядрах работать.
У нас ОЧЕНЬ круто сделано распараллеливание. Всегда используются все ядра процессора автоматически (при желании можно использовать только часть, регулируется в настройках). Это позволяет на машине с четыремя ядрами иметь неплохую производительность. Большинство инструментов не поддерживают несколько ядер.
Так что тут рекомендация такая — ядер побольше и будет хорошо. Один наш клиент (пользователи Site License) купил продукт после того, как на его 16-ядерной машине мы стали на всех ядрах работать.
«Пока мерил заметил, что вызывается компилятор для препроцессинга, появляются файлы *.i.»
Да. Мы пока вынуждены использовать для препроцессирования файлов компилятор Visual C++.
Да. Мы пока вынуждены использовать для препроцессирования файлов компилятор Visual C++.
а почему express версии не поддерживаюся?
Хорошая работа, земляки!
а почему express версии не поддерживаются?
хм… интересненько, нужно будет позже поковырять. Кстати а свои правила писать можно? А то можно было бы приделать некоторые Qt specific косяки.
Ниже я приведу текст, который уже не однократно использовал в ответах на такие вопросы. Поэтому не принимайте «тон» ответа на свой счет :-).
— Бывают клиенты, которые задают довольно глупый вопрос: «А у вас можно собственные правила реализовывать в инструменте?» Вопрос этот глупый потому, что стороннему пользователю не хватит ни квалификации, ни тем более желания для того, чтобы самостоятельно реализовать правило. Но в ответ на этот глупый вопрос sales-manager уверенно достает какой-нибудь чудо-инструмент и говорит: «Конечно, Вы легко можете реализовать любые правила!». И клиент довольный успокаивается. Повторюсь, никогда он сам правила не реализует при этом.
----------------
— Бывают клиенты, которые задают довольно глупый вопрос: «А у вас можно собственные правила реализовывать в инструменте?» Вопрос этот глупый потому, что стороннему пользователю не хватит ни квалификации, ни тем более желания для того, чтобы самостоятельно реализовать правило. Но в ответ на этот глупый вопрос sales-manager уверенно достает какой-нибудь чудо-инструмент и говорит: «Конечно, Вы легко можете реализовать любые правила!». И клиент довольный успокаивается. Повторюсь, никогда он сам правила не реализует при этом.
----------------
Ну я видимо этим займусь не раньше, чем появится возможность прикрутить анализатор хотя-бы к MinGW или clang'у, а то профессиональной студии у меня нема.
Так что это скорее празное любопытство относительно архитектуры.
Так что это скорее празное любопытство относительно архитектуры.
Даже на праздное любопытство я отвечу серьезно. Не занимайтесь чужой работой. Вам нужны какие-то правила? Пишите, мы их сделаем.
Ну в общем ваш подход в корне неверный.
Предположим, у меня есть некий сложный класс, реализующий общение с какой-нибудь железкой, для работы с которой нужно выдерживать некий протокол. Для примера, нужно сначала «открыть» какую-либо фичу, потом из неё прочитать данные, потом _обязательно_ её закрыть.
Описать эту логику работы внутри самого класса конечно можно, но эта проверка пройдет уже немножко поздно. Когда всё уже крутится на реальном железе — даже если мой код самостоятельно выявил ошибку в протоколе, то, в общем, уже непонятно, что я могу тут сделать. Поэтому мне нужен инструмент именно для статической проверки кода в compile-time.
Класс мой внутренний, доступа к нему вы не имеете, ну и не ваше это дело писать правила для чужих внутренних классов.
Поэтому мне нужен статический анализатор кода, для которого я могу писать свои правила.
Впрочем, я точно не буду его покупать у горе-продавца, который заранее называет таких как я «глупыми».
Предположим, у меня есть некий сложный класс, реализующий общение с какой-нибудь железкой, для работы с которой нужно выдерживать некий протокол. Для примера, нужно сначала «открыть» какую-либо фичу, потом из неё прочитать данные, потом _обязательно_ её закрыть.
Описать эту логику работы внутри самого класса конечно можно, но эта проверка пройдет уже немножко поздно. Когда всё уже крутится на реальном железе — даже если мой код самостоятельно выявил ошибку в протоколе, то, в общем, уже непонятно, что я могу тут сделать. Поэтому мне нужен инструмент именно для статической проверки кода в compile-time.
Класс мой внутренний, доступа к нему вы не имеете, ну и не ваше это дело писать правила для чужих внутренних классов.
Поэтому мне нужен статический анализатор кода, для которого я могу писать свои правила.
Впрочем, я точно не буду его покупать у горе-продавца, который заранее называет таких как я «глупыми».
>> который заранее называет таких как я «глупыми».
Глупым я называл вопрос.
>> для которого я могу писать свои правила
Да ради бога. Просто вот ну ни разу не видел я человека со стороны, который бы мог писать правила для статического анализатора. Потому что для этого нужна квалификация.
Глупым я называл вопрос.
>> для которого я могу писать свои правила
Да ради бога. Просто вот ну ни разу не видел я человека со стороны, который бы мог писать правила для статического анализатора. Потому что для этого нужна квалификация.
Извините, не вижу ничего принципиально сложного в написании регекспа или задании списка разрешенных переходов в конечном автомате. А уж написание правил для выявления «ошибок» вида
«3270 V801 Decreased performance. It is better to redefine the first function argument as a reference. Consider replacing 'const… fmt' with 'const… &fmt'.»
— это, извините, вообще детский сад, доступный любой «блондинке», если под блондинкой понимать среднестатистического пользователя вашего продукта.
«3270 V801 Decreased performance. It is better to redefine the first function argument as a reference. Consider replacing 'const… fmt' with 'const… &fmt'.»
— это, извините, вообще детский сад, доступный любой «блондинке», если под блондинкой понимать среднестатистического пользователя вашего продукта.
Детский сад — это то что Вы планируете с Си++ на регекспах работать.
Извините, но ни фига Вы это регекспом не напишите. Уж поверьте. Даже в самом простом случае:
Вам требует знать тип A. Если A это int, то ругаться смысла нет. Если это класс, то стоит ругнуться. Хотел бы я посмотреть, как вы регекспом будете в Си++ программе раскрывать тип.
Не знаете предметную область — не пишите.
void Foo(const A x) {}Вам требует знать тип A. Если A это int, то ругаться смысла нет. Если это класс, то стоит ругнуться. Хотел бы я посмотреть, как вы регекспом будете в Си++ программе раскрывать тип.
Не знаете предметную область — не пишите.
Не знаете предметную область — не пишите правила.
В приведенном мной примере параметр fmt имел тип std:string.
Во-первых, во всех компиляторах стандартный string и так заоптимизирован, замена передачи по значению на передачу по ссылке не даст вообще никакого роста производительности.
Зато, и это во-вторых, передача параметров по ссылке требует наличия объекта. В частности, я не смогу передать в качестве аргумента выражение «a»+«b». Короче, ваш продукт дал очень, очень плохой совет. И таких с позволения сказать «советов» в моём проекте больше половины. Увы.
В приведенном мной примере параметр fmt имел тип std:string.
Во-первых, во всех компиляторах стандартный string и так заоптимизирован, замена передачи по значению на передачу по ссылке не даст вообще никакого роста производительности.
Зато, и это во-вторых, передача параметров по ссылке требует наличия объекта. В частности, я не смогу передать в качестве аргумента выражение «a»+«b». Короче, ваш продукт дал очень, очень плохой совет. И таких с позволения сказать «советов» в моём проекте больше половины. Увы.
«Во-первых, во всех компиляторах стандартный string и так заоптимизирован, замена передачи по значению на передачу по ссылке не даст вообще никакого роста производительности.»
Ох уж мне эти теоретические рассуждения. Не поленился и сделал тестовый пример:
Вывод программы (Visual Studio 2008, Release X64):
Нет, я понимаю, конечно, что случаи бывают разные. Если работа со строками не основное, то пытаться что-то оптимизировать — смысла нет и даже вредно. Всё это я знаю. Но, например, в моем случае (внутри PVS-Studio) я роскошь предавать строки по значению не имею. И бывают другие такие проекты. Смысл статической диагностики — показать подобные места. А уже программисту решать, интересны они или нет. Не интересны — правило можно отключить. Тем более эта диагностика вообще третьего уровня.
Кстати, если это не std::string, то иногда результат передачи по значению может быть намного печальней.
Ох уж мне эти теоретические рассуждения. Не поленился и сделал тестовый пример:
size_t FooValue(const string s1, const string s2)
{
return s1.find(s2);
}
size_t FooRef(const string &s1, const string &s2)
{
return s1.find(s2);
}
...
{
string str("a12345bcdef!");
size_t x = 0;
Timing metric1, metric2;
metric1.StartTiming();
for (size_t i = 0; i != 5000000; ++i)
x += FooValue(str, str);
metric1.StopTiming();
cout << "Value. Total time : " << metric1.GetUserSeconds() << endl;
metric2.StartTiming();
for (size_t i = 0; i != 5000000; ++i)
x += FooRef(str, str);
metric2.StopTiming();
cout << "Reference. Total time : " << metric2.GetUserSeconds() << endl;
cout << x << endl;
}
Вывод программы (Visual Studio 2008, Release X64):
Value. Total time : 0.499449 Reference. Total time : 0.130523 0
Нет, я понимаю, конечно, что случаи бывают разные. Если работа со строками не основное, то пытаться что-то оптимизировать — смысла нет и даже вредно. Всё это я знаю. Но, например, в моем случае (внутри PVS-Studio) я роскошь предавать строки по значению не имею. И бывают другие такие проекты. Смысл статической диагностики — показать подобные места. А уже программисту решать, интересны они или нет. Не интересны — правило можно отключить. Тем более эта диагностика вообще третьего уровня.
Кстати, если это не std::string, то иногда результат передачи по значению может быть намного печальней.
>Во-первых, во всех компиляторах стандартный string и так заоптимизирован, замена передачи по значению на передачу по ссылке не даст вообще никакого роста производительности.
Во-первых, string — часть не компилятора, а стандартной библиотеки (которая вполне может быть сторонней — например, STLPort).
Во-вторых, я не слышал о том, чтобы Copy-On-Write действительно было реализовано в большинстве реализаций стандартной библиотеки, потому как реализация этого механизма с учетом многопоточности не так проста, как кажется, а в некоторых случаях эта оптимизация вылезает боком.
>передача параметров по ссылке требует наличия объекта. В частности, я не смогу передать в качестве аргумента выражение «a»+«b».
Передача по константной ссылке не требует наличия объекта.
А за попытку передачи временных объектов по неконстантой ссылке нужно бить молотком по пальцам.
Во-первых, string — часть не компилятора, а стандартной библиотеки (которая вполне может быть сторонней — например, STLPort).
Во-вторых, я не слышал о том, чтобы Copy-On-Write действительно было реализовано в большинстве реализаций стандартной библиотеки, потому как реализация этого механизма с учетом многопоточности не так проста, как кажется, а в некоторых случаях эта оптимизация вылезает боком.
>передача параметров по ссылке требует наличия объекта. В частности, я не смогу передать в качестве аргумента выражение «a»+«b».
Передача по константной ссылке не требует наличия объекта.
А за попытку передачи временных объектов по неконстантой ссылке нужно бить молотком по пальцам.
Тут нужно всего-лишь sizeof(A) от компилятора заполучить, если он больше, чем sizeof(ptr_diff) тогда const A & круче, а если меньше ну тогда лучше по значению передавать.
А вот например статическую чекалку соответствия между сигналами и слотами в Qt таки даже «блондинка» сможет реализовать. А вещь оч нужная в хозяйстве, ибо часто бывает, что случайно накосячишь, а компилятор спокойно съест. Дополнительным бонусом была бы проверка на namespace'ы ибо тут можно легко сделать код, который будет работать в Linux'е и при этом даже не линковаться при помощи студии.
А вот например статическую чекалку соответствия между сигналами и слотами в Qt таки даже «блондинка» сможет реализовать. А вещь оч нужная в хозяйстве, ибо часто бывает, что случайно накосячишь, а компилятор спокойно съест. Дополнительным бонусом была бы проверка на namespace'ы ибо тут можно легко сделать код, который будет работать в Linux'е и при этом даже не линковаться при помощи студии.
>Дополнительным бонусом была бы проверка на namespace'ы ибо тут можно легко сделать код, который будет работать в Linux'е и при этом даже не линковаться при помощи студии.
Не менее легко можно сделать код, который будет работать в Linux, но не будет линковаться в mingw-gcc (или будет линковаться, но не будет потом работать) под Windows (hint: dllimport, dllexport).
Не менее легко можно сделать код, который будет работать в Linux, но не будет линковаться в mingw-gcc (или будет линковаться, но не будет потом работать) под Windows (hint: dllimport, dllexport).
Я подозреваю, что для того, чтобы пользователи смогли писать свои правила, надо будет сделать доступ к внутреннему представлению дерева программы (и хорошо если хватит С++, а не надо будет питон/перл и т.д.), а также его тщательно документировать…
При этом, чтобы разобраться в дереве, которое front-end компилятор строит для С++ уйдет, скорее всего, не один день…
При этом в реале на это будут способны, скорее всего, единицы… А сил уйдет на поддержку всего этого очень много. Проще добавлять в анализатор правила, присланные пользователями, благо сделать компактный пример не должно вызывать проблем…
При этом, чтобы разобраться в дереве, которое front-end компилятор строит для С++ уйдет, скорее всего, не один день…
При этом в реале на это будут способны, скорее всего, единицы… А сил уйдет на поддержку всего этого очень много. Проще добавлять в анализатор правила, присланные пользователями, благо сделать компактный пример не должно вызывать проблем…
Спасибо. Вы всё правильно понимаете!
Я просто работал «в одной маленькой компиляторной компании» (interstron.ru) и наблюдал какие проблемы возникают с разбором дерева…
Вообще идея хорошая: сделать некий интерфейс через который бы можно было отправлять заведомо кривые и глючные участки кода, которые при этом молча без какого-либо лая со стороны компилятора собираются и даже возможно в некоторых случаях работают так, как ожидается.
Понимаете, у них либо есть документация по написанию правил, ну хотя бы для внутреннего использования, и тогда ничего не мешает её выложить для интересующихся. Либо этой документации нет или она очень низкого качества, и тогда их продукт в реальной разработке применять вообще нельзя. Выше я привел пример вредного совета, который их система дала на ровном месте. Указанное ими правило конечно взято из умной книжки про эффективный Си++, вот только там Мейерс 20 страниц объяснял, когда и как это правило можно применять, а когда нельзя. А они эти пояснения… по факту проигнорировали.
Моё сугубо личное мнение состоит в том, что одного-двух-пяти виртуозов Си++ недостаточно, чтобы описать хоть какой-то набор правил для автоматического анализа. На каждое правило найдется контр-правило, десяток ограничений и сотня исключений, и выяснить их все одному человеку или даже одной организации ну никак невозможно.
Статистический анализатор может быть полезен и работоспособен только в случае создания широкого сообщества пользователей, которые будут тестировать и вылизывать базовые правила, создавать, обмениваться и обсуждать свои наборы правил и так далее. Да, пусть непосредственно создавать правила будет 1% всех юзеров. Еще 3% будут способны прочитать код правил и понять где ошибка, и возможно её подправить. Остальные 96% будут тупо тестерами. Но все они могут появится только при наличии открытого сообщества вокруг анализатора. Иначе никак.
Да, для компании-разработчика это конечно затраты. Но они очень очень быстро отбиваются. Хотя бы на найме специалистов, способных писать правила.
Моё сугубо личное мнение состоит в том, что одного-двух-пяти виртуозов Си++ недостаточно, чтобы описать хоть какой-то набор правил для автоматического анализа. На каждое правило найдется контр-правило, десяток ограничений и сотня исключений, и выяснить их все одному человеку или даже одной организации ну никак невозможно.
Статистический анализатор может быть полезен и работоспособен только в случае создания широкого сообщества пользователей, которые будут тестировать и вылизывать базовые правила, создавать, обмениваться и обсуждать свои наборы правил и так далее. Да, пусть непосредственно создавать правила будет 1% всех юзеров. Еще 3% будут способны прочитать код правил и понять где ошибка, и возможно её подправить. Остальные 96% будут тупо тестерами. Но все они могут появится только при наличии открытого сообщества вокруг анализатора. Иначе никак.
Да, для компании-разработчика это конечно затраты. Но они очень очень быстро отбиваются. Хотя бы на найме специалистов, способных писать правила.
У них, скорее всего, есть просто описание дерева разбора программы, возможно даже от покупного фронт-енд компилятора… если компилятор вообще покупной — тут может быть даже вопрос лицензии на него…
При этом, когда такие вещи пишутся, скорее вообще могли не думать об удобстве использования дерева, а скорее о производительности и универсальности, например…
Вот я лично в своё время разбирался в хорошо описанной документации на похожий компилятор. Да, мелочи править получилось через неделю, наверное, что-то своё новое, разбирающее куски дерева — ощутимо позже…
При этом, я вообще сомневаюсь что можно написать правила, которые не будут давать вообще ложных срабатываний… Как и «допатчить» эти правила в исходниках под свои условия… Скорее, более простым в использовании будет возможность инструмента набирать статистику под конкретного пользователя и выставление под него приоритетов в показе тех или иных предупреждений…
Если не путаю, Интерстрон в свое время отдавал бесплатно свой фронт-енд компилятор в какой-то версии… Народ его вполне тестировал на своих исходниках, но вот чтобы кто-то что-то написал своего из разбора — не помню… Там временные затраты были человеко-годы…
Компания разработчик, насколько я понимаю, первоначально занималась 64 битами, сейчас пытается делать дополнительные движения… Возможно, когда они наберут базу правил побольше, появится у них реальный опыт, они смогут на основе этого опыта сделать какое-то над-API для задания каких-то правил или коррекции имеющихся, но требовать доступа «к кишкам» от бета-версии, кмк рановато…
При этом, когда такие вещи пишутся, скорее вообще могли не думать об удобстве использования дерева, а скорее о производительности и универсальности, например…
Вот я лично в своё время разбирался в хорошо описанной документации на похожий компилятор. Да, мелочи править получилось через неделю, наверное, что-то своё новое, разбирающее куски дерева — ощутимо позже…
При этом, я вообще сомневаюсь что можно написать правила, которые не будут давать вообще ложных срабатываний… Как и «допатчить» эти правила в исходниках под свои условия… Скорее, более простым в использовании будет возможность инструмента набирать статистику под конкретного пользователя и выставление под него приоритетов в показе тех или иных предупреждений…
Если не путаю, Интерстрон в свое время отдавал бесплатно свой фронт-енд компилятор в какой-то версии… Народ его вполне тестировал на своих исходниках, но вот чтобы кто-то что-то написал своего из разбора — не помню… Там временные затраты были человеко-годы…
Компания разработчик, насколько я понимаю, первоначально занималась 64 битами, сейчас пытается делать дополнительные движения… Возможно, когда они наберут базу правил побольше, появится у них реальный опыт, они смогут на основе этого опыта сделать какое-то над-API для задания каких-то правил или коррекции имеющихся, но требовать доступа «к кишкам» от бета-версии, кмк рановато…
>> Статистический анализатор может быть полезен и работоспособен только в случае создания широкого сообщества пользователей.
«Статистический» — может и да, только с широким сообществом пользователей.
Мы же занимаемся статическим.
«Статистический» — может и да, только с широким сообществом пользователей.
Мы же занимаемся статическим.
Мне кажется, вам нужны unit tests.
Ну я так понимаю тривиального способа добавлять правила там нету и нужно все компилить…
Вы правы. Только не востребована такая фича. Чтобы написать самому правило диагностики нужно быть «в теме». А сделать добавление правил «для блондинок» нельзя принципиально.
Только обижаться не надо на блондинок.
Только обижаться не надо на блондинок.
Да, сейчас такого интерфейса нет. Его можно сделать, но это огромная задача. И главная она практически не имеет смысла. Хоть сколько-нибудь серьезное правило стороннему человеку будет крайне сложно/невозможно реализовать самостоятельно. Возникает вопрос, если реализация требует погружения в область статического анализа, а так же собственно требует усилий на реализацию, то не лучше ли использовать свои силы для своих проектов, а реализацию правил передать людям которые сделают это быстрее и дешевле. Следует понимать, что реализация самому дороже, чем оплата этой реализации (например, нам).
Не всегда есть потребность городить какие-то сложные правила.
Есть порой очень специфические правила, которые разработчик встраивать в свою систему не будет, но они довольно легко реализуются.
Правда для таких вещей зачастую хватает регулярных выражений или скрипта на питоне, но на все 100% они не спасают да и не очень удобно — поэтому тоже мелькнула мысль о каком-нибудь конструкторе правил. Хотя это ваш хлеб — новые правила — новые версии студии.
Хотя в целом продукт не плохой — пару мест с потенциальными граблями нашёл, а местами повеселил от «индуского» кода в нутри проектов :)
Есть порой очень специфические правила, которые разработчик встраивать в свою систему не будет, но они довольно легко реализуются.
Правда для таких вещей зачастую хватает регулярных выражений или скрипта на питоне, но на все 100% они не спасают да и не очень удобно — поэтому тоже мелькнула мысль о каком-нибудь конструкторе правил. Хотя это ваш хлеб — новые правила — новые версии студии.
Хотя в целом продукт не плохой — пару мест с потенциальными граблями нашёл, а местами повеселил от «индуского» кода в нутри проектов :)
>> Есть порой очень специфические правила, которые разработчик встраивать в свою систему не будет, но они довольно легко реализуются.
Мы встраиваем такие специфичные правила. Поскольку их легко сделать выключенными по-умолчанию, то они не мешают другим пользователям.
>> Хотя это ваш хлеб — новые правила
Это так. Но прежде все-таки я повторюсь. Пользователь-программист сам НЕ напишет хоть сколько-нибудь адекватное правило, потому что это сложно. Мне теоретики говорят, что «нет, не сложно, мы напишем...». Но на то они и теоретики. Уж я то знаю, что такое «написать правило».
Мы встраиваем такие специфичные правила. Поскольку их легко сделать выключенными по-умолчанию, то они не мешают другим пользователям.
>> Хотя это ваш хлеб — новые правила
Это так. Но прежде все-таки я повторюсь. Пользователь-программист сам НЕ напишет хоть сколько-нибудь адекватное правило, потому что это сложно. Мне теоретики говорят, что «нет, не сложно, мы напишем...». Но на то они и теоретики. Уж я то знаю, что такое «написать правило».
«Есть порой очень специфические правила, которые разработчик встраивать в свою систему не будет».
А вот с этим проблем никаких нет. У нас уже есть пара правил сделанных на заказ. Они весьма специфичны, но по умолчанию отключены и никак другим не мешают.
А вот с этим проблем никаких нет. У нас уже есть пара правил сделанных на заказ. Они весьма специфичны, но по умолчанию отключены и никак другим не мешают.
Можно дам вам совет как один из разработчиков статического анализатора кода для Verilog/VHDL?:)
Практика показывает, что клиенты всегда спрашивают API для написания правил, но очень редко его используют. Видимо, им на душе спокойнее, если им кажется, будто бы они способны написать плагин с правилами сами. Поэтому галочка «есть возможность реализации собственных правил» — это большой плюс для вас, даже если эта возможность будет ограниченной.
У нас, кстати, была проблема с предоставлением API: если встроенные rule plugins работали с объектно-ориентированной C++-моделью, то для пользовательских плагинов пришлось сделать громоздкий сишный интерфейс (из-за несовместимости ABI различных C++-компиляторов). Как я понимаю, вы же привязываетесь к конкретному компилятору, поэтому у вас таких проблем возникнуть вроде бы не должно.
P.S. Старайтесь поменьше употреблять фразу «клиенты задают глупый вопрос», даже если это и правда:).
Практика показывает, что клиенты всегда спрашивают API для написания правил, но очень редко его используют. Видимо, им на душе спокойнее, если им кажется, будто бы они способны написать плагин с правилами сами. Поэтому галочка «есть возможность реализации собственных правил» — это большой плюс для вас, даже если эта возможность будет ограниченной.
У нас, кстати, была проблема с предоставлением API: если встроенные rule plugins работали с объектно-ориентированной C++-моделью, то для пользовательских плагинов пришлось сделать громоздкий сишный интерфейс (из-за несовместимости ABI различных C++-компиляторов). Как я понимаю, вы же привязываетесь к конкретному компилятору, поэтому у вас таких проблем возникнуть вроде бы не должно.
P.S. Старайтесь поменьше употреблять фразу «клиенты задают глупый вопрос», даже если это и правда:).
Спасибо за комментарий, конечно же я с Вами согласен (как следует из моих ответов).
Прокомментирую только одну вещь:
>> P.S. Старайтесь поменьше употреблять фразу «клиенты задают глупый вопрос», даже если это и правда:).
Вы не представляете, какое чувство свободы появляется, если работаешь в маленькой компании и можешь говорить правду :-). Это в крупных мега-корпорациях есть 1000-страничные инструкции на тему как общаться, как использовать обороты типа «на это вопрос уполномочен ответить только вице-президент пиар-отдела службы по связами с общественностью».
А мы — простые ребята, можем спокойно говорить от своего имени. Большинство клиентов такую прямоту ценят, так как сами разработчики ПО, а не бла-бла-бла-пиарщики :-).
Прокомментирую только одну вещь:
>> P.S. Старайтесь поменьше употреблять фразу «клиенты задают глупый вопрос», даже если это и правда:).
Вы не представляете, какое чувство свободы появляется, если работаешь в маленькой компании и можешь говорить правду :-). Это в крупных мега-корпорациях есть 1000-страничные инструкции на тему как общаться, как использовать обороты типа «на это вопрос уполномочен ответить только вице-президент пиар-отдела службы по связами с общественностью».
А мы — простые ребята, можем спокойно говорить от своего имени. Большинство клиентов такую прямоту ценят, так как сами разработчики ПО, а не бла-бла-бла-пиарщики :-).
И еще: у нас был клиент — компания из Индии — которая купила базовую комплектацию (без большинства встроенных rule plugins) и написала свой плагин для правил, с блэкджеком и шлюхами навигатором по семантическому дереву и регулярками.
Так что иногда эта фича действительно востребована :)
Так что иногда эта фича действительно востребована :)
А под нормальные ОС нету.
Так ведь в нормальной ОС нормальные идеальные безглючные программы. Разве не так? Так зачем же вам тогда там анализатор? :)))
передергиваете :) под нормальную ось программы такие же глючные как и под ненормальную, просто косяки проще исправить даже самостоятельно если разработчики не спешат…
ну и еще там есть архиполезный valgrind, спасибо ему за всё! :))
ну и еще там есть архиполезный valgrind, спасибо ему за всё! :))
>Так ведь в нормальной ОС нормальные идеальные безглючные программы. Разве не так?
Неумелая попытка троллинга не делает чести разработчику серьёзной программы.
Почему бы просто честно не сказать «в нашей компании нет ни одного человека, кто мог бы собрать наш проект под другую ОС»?
Неумелая попытка троллинга не делает чести разработчику серьёзной программы.
Почему бы просто честно не сказать «в нашей компании нет ни одного человека, кто мог бы собрать наш проект под другую ОС»?
По поводу троллинга. А не люблю я таких линуксойдов. Уж извините. Будет нормальный вопрос — будет нормальный ответ.
По поводу сборки под Linux. Дурное дело не хитрое. Уж поверьте, захотим — соберем. Вы лучше скажите, как потом на этом денег заработать? :) Ваша компания готова финансировать разработку, хотя бы частично?
По поводу сборки под Linux. Дурное дело не хитрое. Уж поверьте, захотим — соберем. Вы лучше скажите, как потом на этом денег заработать? :) Ваша компания готова финансировать разработку, хотя бы частично?
>По поводу троллинга. А не люблю я таких линуксойдов. Уж извините. Будет нормальный вопрос — будет нормальный ответ.
Ну, во-первых с чего Вы взяли, что вопрос был про Linux? Может человек имел в виду Mac OS X?
А во-вторых, Вы, конечно, имеете право любить или не любить, но (ИМХО, разумеется) не тогда, когда говорите от лица компании. А в данном топике Вы (как мне казалось) делаете именно это.
>Уж поверьте, захотим — соберем.
>Вы лучше скажите, как потом на этом денег заработать?
Вы хотите, чтобы я разработал Вам маркетинг-план? Можем обсудить, не вопрос.
На самом деле вопрос очень странный. «Как нам заработать на Linux-версии билд-сервера?», «Как нам заработать на Linux-версии VCS-сервера?» — думаю, данные вопросы Вам покажутся весьма странными, верно? Это на правах намёка.
Впрочем, можете не слушать и продолжать минусовать дальше — в конце-концов это Ваш бизнес, не мой.
>Ваша компания готова финансировать разработку, хотя бы частично?
Наша компания с подозрением относится к разработчикам, которые общаются с потенциальными клиентами подобным образом.
Ну, во-первых с чего Вы взяли, что вопрос был про Linux? Может человек имел в виду Mac OS X?
А во-вторых, Вы, конечно, имеете право любить или не любить, но (ИМХО, разумеется) не тогда, когда говорите от лица компании. А в данном топике Вы (как мне казалось) делаете именно это.
>Уж поверьте, захотим — соберем.
— Да если я захочу, у меня будет сто волшебных палочек!© «Незнайка в Солнечном Городе»
— Почему же у тебя их нет?
— А потому что я не хочу.
>Вы лучше скажите, как потом на этом денег заработать?
Вы хотите, чтобы я разработал Вам маркетинг-план? Можем обсудить, не вопрос.
На самом деле вопрос очень странный. «Как нам заработать на Linux-версии билд-сервера?», «Как нам заработать на Linux-версии VCS-сервера?» — думаю, данные вопросы Вам покажутся весьма странными, верно? Это на правах намёка.
Впрочем, можете не слушать и продолжать минусовать дальше — в конце-концов это Ваш бизнес, не мой.
>Ваша компания готова финансировать разработку, хотя бы частично?
Наша компания с подозрением относится к разработчикам, которые общаются с потенциальными клиентами подобным образом.
На тему PVS-Studio Standalone и Linux, возможно будет интересна вот эта новая заметка — "PVS-Studio теперь работает и без среды Visual Studio или C++Builder – проверяем препроцессированные файлы от чего угодно".
>> Почему бы просто честно не сказать «в нашей компании нет ни одного человека, кто мог бы собрать наш проект под другую ОС»?
В нашей компании нет ни одного человека, кто мог бы собрать наш проект под другую ОС. Потому что наши сотрудники занимаются разработкой инструмента для Windows-платформы. Что в этом стыдного?
В нашей компании нет ни одного человека, кто мог бы собрать наш проект под другую ОС. Потому что наши сотрудники занимаются разработкой инструмента для Windows-платформы. Что в этом стыдного?
Так это Вы мне расскажите, что в этом настолько стыдного, что этот простой (и по сути нейтральный) факт одним из сотрудников компании преподносится с издёвкой «а разве под другой ОСью не идеальные безглючные программы?» и «захотим — соберём, но просто не хотим».
Я и в мыслях не имел подразумевать под этим фактом что-то стыдное, я всего лишь сказал, что предпочитаю прямые честные ответы неуместным (опять же, на мой взгляд) кривляниям.
Я и в мыслях не имел подразумевать под этим фактом что-то стыдное, я всего лишь сказал, что предпочитаю прямые честные ответы неуместным (опять же, на мой взгляд) кривляниям.
Я его накажу завтра.
P.S. Иногда от Linux-сообщества идет слишком большой поток энергии. Поэтому и реакция такая.
P.S. Иногда от Linux-сообщества идет слишком большой поток энергии. Поэтому и реакция такая.
>Я его накажу завтра.
Улыбнуло. В прямом смысле. Честно. Вот сижу и улыбаюсь теперь :)
>Иногда от Linux-сообщества идет слишком большой поток энергии.
Любую энергию (включая ту, которая исходит от Linux-сообщества) можно обернуть во благо. В том числе и в материальное (в перспективе).
>Поэтому и реакция такая.
Одно из качеств профессионала — отрешиться от эмоций и личных предпочтений.
P.S.: да, я знаю, что я идеалист.
Улыбнуло. В прямом смысле. Честно. Вот сижу и улыбаюсь теперь :)
>Иногда от Linux-сообщества идет слишком большой поток энергии.
Любую энергию (включая ту, которая исходит от Linux-сообщества) можно обернуть во благо. В том числе и в материальное (в перспективе).
>Поэтому и реакция такая.
Одно из качеств профессионала — отрешиться от эмоций и личных предпочтений.
P.S.: да, я знаю, что я идеалист.
Я вот например не очень понимаю проблем, почему сразу нельзя было без доп усилий анализатор кроссплатформенным делать. Помню только однажды услышал слова про препроцессор студийный, который у вас юзается. Но блин, что мешает заюзать gccшный или любой другой по выбору?
>> почему сразу нельзя было без доп усилий анализатор кроссплатформенным делать
Очевидно потому, что каждая новая платформа существенно удорожает стоимость разработки.
>> Но блин, что мешает заюзать gccшный или любой другой по выбору?
Ничего не мешает. Да, можно использовать любой другой.
Очевидно потому, что каждая новая платформа существенно удорожает стоимость разработки.
>> Но блин, что мешает заюзать gccшный или любой другой по выбору?
Ничего не мешает. Да, можно использовать любой другой.
>>Очевидно потому, что каждая новая платформа существенно удорожает стоимость разработки.
Если существенно удорожает, значит архитектура у ПО неудачная ибо фактически 1. Ваше ПО по большей части не завязано на gui, исключением является только плагин для студии.
2. Ваше ПО не работает с оборудованием и ему не нужны windows specific фичи никаким местом.
3. Фактически у вашего ПО не так уж и много способов общения с внешним миром. Основная нагрузка же идёт на разбор полученного кода.
То есть тут вообще нету никаких обстоятельств, которые не давали бы сразу писать ПО переносимым. А раз уж прибили гвоздями его к Студии, то это уже собсна ваши проблемы. На других платформах подобный софт тоже был бы востребован и сейчас подобная тулза активно разрабатывается при содействии Apple. Вы не боитесь остаться у разбитого корыта, когда они начнут добиваться серъезных успехов? Напомню их утилита изначально кроссплатформенная, работает почти с любым компилятором и при этом полностью opensource и уже сейчас дает неплохие результаты при анализе Сишного и obj-c кода (С++ пока хромает несмотря даже на то, что сама утилита на нём написана).
Если существенно удорожает, значит архитектура у ПО неудачная ибо фактически 1. Ваше ПО по большей части не завязано на gui, исключением является только плагин для студии.
2. Ваше ПО не работает с оборудованием и ему не нужны windows specific фичи никаким местом.
3. Фактически у вашего ПО не так уж и много способов общения с внешним миром. Основная нагрузка же идёт на разбор полученного кода.
То есть тут вообще нету никаких обстоятельств, которые не давали бы сразу писать ПО переносимым. А раз уж прибили гвоздями его к Студии, то это уже собсна ваши проблемы. На других платформах подобный софт тоже был бы востребован и сейчас подобная тулза активно разрабатывается при содействии Apple. Вы не боитесь остаться у разбитого корыта, когда они начнут добиваться серъезных успехов? Напомню их утилита изначально кроссплатформенная, работает почти с любым компилятором и при этом полностью opensource и уже сейчас дает неплохие результаты при анализе Сишного и obj-c кода (С++ пока хромает несмотря даже на то, что сама утилита на нём написана).
(голосом Крейга из Саус-Парка): «Если бы нас поддерживал Apple я был бы та-а-а-а-к счастлив».
А пока без подобной поддержки я не рискну продавать софт стоимостью в несколько тысяч евро под Linux без полного цикла тестирования как у нас делается на Windows.
А пока без подобной поддержки я не рискну продавать софт стоимостью в несколько тысяч евро под Linux без полного цикла тестирования как у нас делается на Windows.
Меня интересует чисто технически насколько это сложно, про политику я не спрашиваю. Я вообще весьма трепетно к кроссплатформенности отношусь.
Ох, да можно собрать сам модуль анализа. Он на Си++ и практически не использует ничего системного. Но я надеюсь, Вы понимаете, что собрать исполняемый файл и выпустить программный продукт под другую ОС это две большие разницы.
Чисто технически это возможно. Принципиальных проблем нет. Однако это не то же самое, что просто перекомпилировать программку. Дело в том, что сейчас анализатор отлажен для работы с кодом Visual Studio. На Unix-окружении надо отлаживаться под код других компиляторов. Там, разумеется, есть свои специфики. То есть ключевые слова свои, свои типы синтаксиса и т.п. Все это требует как минимум тестирования, сопостовимого с тем, что мы делаем на Windows-платформе.
>Дело в том, что сейчас анализатор отлажен для работы с кодом Visual Studio. На Unix-окружении надо отлаживаться под код других компиляторов
Отделите уже мух от котлет: работать под Linux и анализировать код, написанный для Linux (для сборки другим компилятором, отличным от gcc) — вещи слегка ортогональные. Можно начать с первого и плавно перейти ко второму.
Отделите уже мух от котлет: работать под Linux и анализировать код, написанный для Linux (для сборки другим компилятором, отличным от gcc) — вещи слегка ортогональные. Можно начать с первого и плавно перейти ко второму.
А, это Вы мне говорите, что ЭТО — разное? Спасибо, я как-то не думал об этом раньше.
Как-будто мы не об этом писали…
Как-будто мы не об этом писали…
Уфф, умерьте пыл. Никто не хотел вас зацепить. У вас очень интересный продукт.
Если я правильно понял, что имеют в виду коллеги — «Было бы не плохо и было бы вполне разумно еще на начальном этапе проектирования заложить кроссплатформу как таковую, ибо все предпосылки имеются, а проблемы практически отсутствуют. Да и сейчас не поздно :)» — то присоединяюсь. Возможно мы все ошибаемся, но хотелось бы аргументированного ответа, если вас не затруднит — любой ваш ответ будет интересным опытом (для меня точно).
Речь идет о проблемах формирования «коробочного продукта» под другие платформы? Или в чем проблема?
Если я правильно понял, что имеют в виду коллеги — «Было бы не плохо и было бы вполне разумно еще на начальном этапе проектирования заложить кроссплатформу как таковую, ибо все предпосылки имеются, а проблемы практически отсутствуют. Да и сейчас не поздно :)» — то присоединяюсь. Возможно мы все ошибаемся, но хотелось бы аргументированного ответа, если вас не затруднит — любой ваш ответ будет интересным опытом (для меня точно).
Речь идет о проблемах формирования «коробочного продукта» под другие платформы? Или в чем проблема?
Дело в том, что программисты любят решать программистские задачи. Им ИНТЕРЕСНО решать всякие головоломки как сделать ту или иную техническую штучку.
Мне же помимо программистских задач, приходится решать и бизнес-задачи. А именно: как продать продукт, кому, как обеспечить определенный уровень качества продаваемого решения.
Например, для решения последнего вопроса (про обеспечение качества нашего продукта) мы используем всевозможные тесты. В статье «Как мы тестируем анализатор кода», вышедшей более года назад, приведены лишь некоторые наши методы обеспечения качества. Сейчас их уже больше, например, добавилось UI-тестирование. Для того чтобы быть уверенным в работоспособности продукта под другой системой перенести все тесты (точнее все типы тестов) на нее это как ну совершенно необходимый минимум. Но не достаточный конечно.
Помимо этого есть вопросы разработки документации для новой системы, дополнительная поддержка пользователей. Тут на Windows-то иногда диву даешься: «Ну надо же, и такие конфигурации бывают». А с другими системами этого будет значительно больше.
И вот, зная и понимая эту ситуацию я вижу комментарий: «Да ладно, вы просто скомпилируйте exe-шник под Linux и будет все круто!». Что мне на это ответить?
Мне же помимо программистских задач, приходится решать и бизнес-задачи. А именно: как продать продукт, кому, как обеспечить определенный уровень качества продаваемого решения.
Например, для решения последнего вопроса (про обеспечение качества нашего продукта) мы используем всевозможные тесты. В статье «Как мы тестируем анализатор кода», вышедшей более года назад, приведены лишь некоторые наши методы обеспечения качества. Сейчас их уже больше, например, добавилось UI-тестирование. Для того чтобы быть уверенным в работоспособности продукта под другой системой перенести все тесты (точнее все типы тестов) на нее это как ну совершенно необходимый минимум. Но не достаточный конечно.
Помимо этого есть вопросы разработки документации для новой системы, дополнительная поддержка пользователей. Тут на Windows-то иногда диву даешься: «Ну надо же, и такие конфигурации бывают». А с другими системами этого будет значительно больше.
И вот, зная и понимая эту ситуацию я вижу комментарий: «Да ладно, вы просто скомпилируйте exe-шник под Linux и будет все круто!». Что мне на это ответить?
Да, кстати: то, что разрабатываемый вашей компанией инструмент нацелен на разработчиков Windows-софта, никак не говорит о том, что сама PVS-Studio должна работать исключительно под Windows.
В одном из предыдущих ответов техническому директору вашей компании я уже дал довольно прозрачный намёк, но он его или не понял, или проигнорировал (по каким-то своим причинам).
Могу развернуть чуть подробнее, если хотите. Реальность такова, что для более-менее серьёзных проектов статический анализ действительно может занимать часы (где-то выше это уже проскакивало), поэтому делать его на рабочей машине одного из разработчиков нецелесообразно. Целесообразнее перенести эту задачу на отдельно выделенный сервер, как это происходит, к примеру, с билд-машинами. Сценарий использования PVS-Studio в данном случае повторяет сценарий использования билд-машины: запускается анализ, результат выплёвывается в лог с таймстампом и размещается на специальном сайте в интранете (можно, к примеру, сделать интеграцию с тем же Hudson, о котором не так давно писали на Хабре), после чего проверяется SVN/Perforce/Git/whatever-репозиторий на наличие новой ревизии, и если таковая имеется — запускается проверка изменённых файлов. Если изменений не поступало — периодически проверять на наличие коммитов по таймеру (или триггер поставить — не суть).
В результате продукт под названием «PVS-Studio» из утлилиты для статического анализа (которой по сути он является сейчас) моментально перерастает в систему для статического анализа, нужно лишь озаботиться несколькими интеграционными прослойками (с системами контроля версий, с системами мониторинга и т.п.)
А теперь вопрос: Вы видите какие-то технические сложности в реализации данного сценария? Я — нет. Все кирпичики для построения офигенно удобной системы — есть. За исключением одного маленького факта: многие компании по какому-то странному стечению обстоятельств предпочитают держать подобные серверы (для автоматической сборки, автоматического прогона тестов и прочих подобных вещей) под управлением операционной системы из семейства Linux (и я не могу сказать, что не понимаю мотивы, которые ими движут в данном случае). Тот факт, что сами правила анализа [возможно] заточены на Windows-специфичное программирование, роли не играет: ведь никто не запрещает на Linux-сервере анализировать Windows-код, верно?
Подводя итог вышесказанному: если бы ваши сотрудники перестали «заниматься разработкой инструмента для Windows-платформы», а начали бы «заниматься разработкой продукта для удовлетворения потребностей рынка», то компания от этого только выиграла бы. Но на то Вы и генеральный директор, чтобы задавать генеральную линию партии.
А теперь скажите мне честно (так же честно, как Вы сказали в предыдущем комментарии): Вы не видите перспективы в описанном мной сценарии?
В одном из предыдущих ответов техническому директору вашей компании я уже дал довольно прозрачный намёк, но он его или не понял, или проигнорировал (по каким-то своим причинам).
Могу развернуть чуть подробнее, если хотите. Реальность такова, что для более-менее серьёзных проектов статический анализ действительно может занимать часы (где-то выше это уже проскакивало), поэтому делать его на рабочей машине одного из разработчиков нецелесообразно. Целесообразнее перенести эту задачу на отдельно выделенный сервер, как это происходит, к примеру, с билд-машинами. Сценарий использования PVS-Studio в данном случае повторяет сценарий использования билд-машины: запускается анализ, результат выплёвывается в лог с таймстампом и размещается на специальном сайте в интранете (можно, к примеру, сделать интеграцию с тем же Hudson, о котором не так давно писали на Хабре), после чего проверяется SVN/Perforce/Git/whatever-репозиторий на наличие новой ревизии, и если таковая имеется — запускается проверка изменённых файлов. Если изменений не поступало — периодически проверять на наличие коммитов по таймеру (или триггер поставить — не суть).
В результате продукт под названием «PVS-Studio» из утлилиты для статического анализа (которой по сути он является сейчас) моментально перерастает в систему для статического анализа, нужно лишь озаботиться несколькими интеграционными прослойками (с системами контроля версий, с системами мониторинга и т.п.)
А теперь вопрос: Вы видите какие-то технические сложности в реализации данного сценария? Я — нет. Все кирпичики для построения офигенно удобной системы — есть. За исключением одного маленького факта: многие компании по какому-то странному стечению обстоятельств предпочитают держать подобные серверы (для автоматической сборки, автоматического прогона тестов и прочих подобных вещей) под управлением операционной системы из семейства Linux (и я не могу сказать, что не понимаю мотивы, которые ими движут в данном случае). Тот факт, что сами правила анализа [возможно] заточены на Windows-специфичное программирование, роли не играет: ведь никто не запрещает на Linux-сервере анализировать Windows-код, верно?
Подводя итог вышесказанному: если бы ваши сотрудники перестали «заниматься разработкой инструмента для Windows-платформы», а начали бы «заниматься разработкой продукта для удовлетворения потребностей рынка», то компания от этого только выиграла бы. Но на то Вы и генеральный директор, чтобы задавать генеральную линию партии.
А теперь скажите мне честно (так же честно, как Вы сказали в предыдущем комментарии): Вы не видите перспективы в описанном мной сценарии?
Мне право не ловко отвечать на такой большой и хороший комментарий ссылками, но что делать.
1. Использование PVS-Studio вместе с системами continuous integration.
2.Принцип постоянного использования PVS-Studio в процессе разработки программного проекта.
3. Проверка кода с помощью PVS-Studio из командной строки (если есть solution-файл Visual Studio).
Я к тому, что все это есть и уже давно используется как нами, так и клиентами. В частности у нас наш анализатор каждую ночь проверяется на новые ошибки, которые разработчики утром получают в виде e-mail. Все это из CruiseControl.Net. Есть и текстовые логи, и более мощные, для анализа из Visual Studio.
То есть я не только не спорю с Вами, я говорю, что Вы абсолютно правы. Подтверждением чему является реализация этих возможностей у нас.
Но если наши пользователи при этом выбирают Windows — мне же не ругать их за это.
1. Использование PVS-Studio вместе с системами continuous integration.
2.Принцип постоянного использования PVS-Studio в процессе разработки программного проекта.
3. Проверка кода с помощью PVS-Studio из командной строки (если есть solution-файл Visual Studio).
Я к тому, что все это есть и уже давно используется как нами, так и клиентами. В частности у нас наш анализатор каждую ночь проверяется на новые ошибки, которые разработчики утром получают в виде e-mail. Все это из CruiseControl.Net. Есть и текстовые логи, и более мощные, для анализа из Visual Studio.
То есть я не только не спорю с Вами, я говорю, что Вы абсолютно правы. Подтверждением чему является реализация этих возможностей у нас.
Но если наши пользователи при этом выбирают Windows — мне же не ругать их за это.
Отлично! Приятно, когда находишься на одной волне с собеседником.
Вот только последняя строчка не совсем понятна: у Ваших пользователей что, есть какой-то выбор? Если он и есть, то из разряда:
1) использовать Windows и иметь возможность использовать PVS-Studio
2) использовать Linux и не иметь возможности использовать PVS-Studio (а выбрать другое решение)
Сдаётся мне, если последнюю Вашу фразу перефразировать как «нашими пользователями стали только те, кто выбрал Windows», то так будет точнее. Заодно и продемонстрирует Вам, что вы своим странным упорством лишь теряете клиентов.
Одно дело, когда продукт уникален и не имеет аналогов. Но ведь это не Ваш случай, и Вы прекрасно это понимаете, верно? Так что далеко не все клиенты будут скрипеть зубами, но пользоваться Windows ради того, чтобы иметь возможность использовать PVS-Studio — некоторые просто предпочтут решения, более либеральные в вопросе выбора платформы.
Почему Вы своими руками отнимаете у себя клиентов — мне решительно непонятно.
Ладно, я уже произносил ключевую фразу, на которой мне стоило бы закончить, так что придётся повторить и на этот раз действительно закончить: «это Ваш бизнес, не мой, поэтому решать Вам».
Вот только последняя строчка не совсем понятна: у Ваших пользователей что, есть какой-то выбор? Если он и есть, то из разряда:
1) использовать Windows и иметь возможность использовать PVS-Studio
2) использовать Linux и не иметь возможности использовать PVS-Studio (а выбрать другое решение)
Сдаётся мне, если последнюю Вашу фразу перефразировать как «нашими пользователями стали только те, кто выбрал Windows», то так будет точнее. Заодно и продемонстрирует Вам, что вы своим странным упорством лишь теряете клиентов.
Одно дело, когда продукт уникален и не имеет аналогов. Но ведь это не Ваш случай, и Вы прекрасно это понимаете, верно? Так что далеко не все клиенты будут скрипеть зубами, но пользоваться Windows ради того, чтобы иметь возможность использовать PVS-Studio — некоторые просто предпочтут решения, более либеральные в вопросе выбора платформы.
Почему Вы своими руками отнимаете у себя клиентов — мне решительно непонятно.
Ладно, я уже произносил ключевую фразу, на которой мне стоило бы закончить, так что придётся повторить и на этот раз действительно закончить: «это Ваш бизнес, не мой, поэтому решать Вам».
Надеюсь, теперь Вы будете рады: PVS-Studio для Linux. :)
Мне, конечно, немного льстит, что по прошествию 6 лет вы всё ещё помните о нашёй беседе, и не поленились (аж дважды) сообщить лично мне о достигнутых вами результатах, но мне-то с какой стати «радоваться» по поводу того, что для вас стало очевидным то, что для меня было очевидным ещё 6 лет назад? ;)
Я лишь в очередной раз повторю фразу, которую говорил тогда (и которая по удивительному стечению обстоятельств завершает мой предыдущий комментарий в этой ветке): «Это ваш бизнес, не мой».
Но в целом, конечно, поздравляю.
P.S.: но Klocwork наше всё ;)
Я лишь в очередной раз повторю фразу, которую говорил тогда (и которая по удивительному стечению обстоятельств завершает мой предыдущий комментарий в этой ветке): «Это ваш бизнес, не мой».
Но в целом, конечно, поздравляю.
P.S.: но Klocwork наше всё ;)
Расскажите по-подробнее про билд-машины под управлением Linux которые собирают Windows приложения.
Я думаю выбор платформы обусловлен тем, что доля коммерческого софта написанного на С++ под другие платформы очень мала; ну или настолько мала что их не интересует.
Я думаю выбор платформы обусловлен тем, что доля коммерческого софта написанного на С++ под другие платформы очень мала; ну или настолько мала что их не интересует.
>Расскажите по-подробнее про билд-машины под управлением Linux которые собирают Windows приложения.
Самой билд-машине совершенно пофиг, какой набор команд выполнять. Меня тоже это немало удивило, для я первый раз увидел сервер кросс-компиляции, собирающий Вин-программы на Линуксе (при том, что в особых пристрастиях к Линуксу контора замечена не была — и рабочие станции все под Виндой, и подавляющее большинство проектов тоже под Винду).
Заморочки могут быть только в начале — в самой настройке среды для кросс-компиляции, а дальше ничего интересного: тупо запускается определённое задание при определённом условии (новый коммит, таймер, иноэ) и результат выплёвывается в заранее обговоренное место.
>Я думаю выбор платформы обусловлен тем, что доля коммерческого софта написанного на С++ под другие платформы очень мала
Так мы же вроде о Виндовс-софте говорим?
Самой билд-машине совершенно пофиг, какой набор команд выполнять. Меня тоже это немало удивило, для я первый раз увидел сервер кросс-компиляции, собирающий Вин-программы на Линуксе (при том, что в особых пристрастиях к Линуксу контора замечена не была — и рабочие станции все под Виндой, и подавляющее большинство проектов тоже под Винду).
Заморочки могут быть только в начале — в самой настройке среды для кросс-компиляции, а дальше ничего интересного: тупо запускается определённое задание при определённом условии (новый коммит, таймер, иноэ) и результат выплёвывается в заранее обговоренное место.
>Я думаю выбор платформы обусловлен тем, что доля коммерческого софта написанного на С++ под другие платформы очень мала
Так мы же вроде о Виндовс-софте говорим?
Я представляю что такое кросс-компиляция. Но я не припомню чтобы инструменты из студии работали под чем-то кроме Windows. Конечно можно собирать с помощью других инструментов, но возникает вопрос: зачем? Пользователь софта будет работать под Windows, разработчики работают под Windows, тестируется все там же, а собирать будем другими инструментами под Linux?
>>Так мы же вроде о Виндовс-софте говорим?
Я имею ввиду что разработчики PVS выбрали Windows как целевую платформу, потому что под нее значительно больше коммерческого софта.
>>Так мы же вроде о Виндовс-софте говорим?
Я имею ввиду что разработчики PVS выбрали Windows как целевую платформу, потому что под нее значительно больше коммерческого софта.
>Но я не припомню чтобы инструменты из студии работали под чем-то кроме Windows.
Вы, возможно, не поверите, но на студии свет клином не сошёлся. И Вы нимало удивитесь, какое количество коммерческого софта под Windows для сборки использует mingw-gcc, а не студию. А уж про внутренний софт в больших компаниях я и не говорю.
Я, к примеру, был немало удивлён, когда заглянул в каталог одной из внутренних программ и обнаружил там до боли знакомые QtCore4.dll, QtGui4.dll, mingwm10.dll. И программа — не чятик для связи бухгалтеров со складом, сляпанная на коленке, а повседневный инструмент разработчиков (в компании, к слову, ~14K человек) — специальный аддон к Perforce.
Ну а в общем и целом — на рабочем компе в каталоге C:\Program Files\ у меня обнаружилось 4 экземпляра mingwm10.dll.
>Я имею ввиду что разработчики PVS выбрали Windows как целевую платформу, потому что под нее значительно больше коммерческого софта.
Я понимаю, что Вы имеете в виду, но не понимаю, какое это имеет отношение к предмету разговора. Дано: набор исходников и определённый алгоритм их анализа. Вопрос: какая разница, на какой платформе запускать этот алгоритм, натравливая его на эти исходники? Один и тот же алгоритм будет совершенно одинаково работать хоть на Windows, хоть на Linux, хоть на NetBSD, хоть на iPhone.
Вы, возможно, не поверите, но на студии свет клином не сошёлся. И Вы нимало удивитесь, какое количество коммерческого софта под Windows для сборки использует mingw-gcc, а не студию. А уж про внутренний софт в больших компаниях я и не говорю.
Я, к примеру, был немало удивлён, когда заглянул в каталог одной из внутренних программ и обнаружил там до боли знакомые QtCore4.dll, QtGui4.dll, mingwm10.dll. И программа — не чятик для связи бухгалтеров со складом, сляпанная на коленке, а повседневный инструмент разработчиков (в компании, к слову, ~14K человек) — специальный аддон к Perforce.
Ну а в общем и целом — на рабочем компе в каталоге C:\Program Files\ у меня обнаружилось 4 экземпляра mingwm10.dll.
>Я имею ввиду что разработчики PVS выбрали Windows как целевую платформу, потому что под нее значительно больше коммерческого софта.
Я понимаю, что Вы имеете в виду, но не понимаю, какое это имеет отношение к предмету разговора. Дано: набор исходников и определённый алгоритм их анализа. Вопрос: какая разница, на какой платформе запускать этот алгоритм, натравливая его на эти исходники? Один и тот же алгоритм будет совершенно одинаково работать хоть на Windows, хоть на Linux, хоть на NetBSD, хоть на iPhone.
Барт Симпсон:
«Я буду читать, что пишут разработчики PVS-Studio по поводу запуска на Linux, прежде чем напишу очередной свой комментарий.»
«Я буду читать, что пишут разработчики PVS-Studio по поводу запуска на Linux, прежде чем напишу очередной свой комментарий.»
«Я буду чита…
«Я буду читать, что пишут разработчики PVS-Studio по поводу запуска на Linux, прежде чем напишу очередной свой комментарий.»
«Я буду читать, что пишут разработчики PVS-Studio по поводу запуска на Linux, прежде чем напишу очередной свой комментарий.»
«Я буду чита…
Барт, после того, как ты закончишь упражение по чистописанию, подумай, что твоя фраза не к месту, и то, «что пишут разработчики PVS-Studio по поводу запуска на Linux» не даёт исчерпывающего ответа на все поставленные вопросы.
Да я понимаю, что кому-то нравится пофилософствовать про Linux vs Windows, кому-то нравится попровоцировать людей, а кому-то просто скучно.
Но ничего, у меня +100 к спокойствию.
Но ничего, у меня +100 к спокойствию.
Вам бы ещё +100 ко внимательности, ибо темы «что-то vs что-то» разговор и не думал касаться.
Провоцировать — не интересно: Ваш технический директор заводится сам, без посторонней помощи.
Скучно? Ну, есть немного, хотя я изначально был настроен на серьёзный разговор, однако школьное гыгыканье с Вашей стороны как-то не особо к нему располагает, поэтому разговор вчера так быстро закончился. Сегодняшнее Ваше «выступление» желания не прибавило.
Но сижу вот, комментирую от нефиг делать. И нежно жду ответного комментария :)
Провоцировать — не интересно: Ваш технический директор заводится сам, без посторонней помощи.
Скучно? Ну, есть немного, хотя я изначально был настроен на серьёзный разговор, однако школьное гыгыканье с Вашей стороны как-то не особо к нему располагает, поэтому разговор вчера так быстро закончился. Сегодняшнее Ваше «выступление» желания не прибавило.
Но сижу вот, комментирую от нефиг делать. И нежно жду ответного комментария :)
Да, кстати, после Крейга и Барта уважаемый генеральный директор серьёзной софтверной компании мог бы процитировать, к примеру, Бендера: «Bite my shiny metal ass». Собственно, с этой фразы он мог бы начать (раз уж смысл всё равно к этом свёлся) — тогда никаких вопросов бы не возникало.
Я верю, верю. Но какое количество? С виду может и много, а в процентах сколько? И вы сюда точно не включаете кроссплатформенный софт?
Я вот тоже не знаю ответов, но предполагаю что заказчики PVS знают. И из того что они сделали версию только под студию я делаю вывод что они нацелились на подавляющую часть рынка.
>Я имею ввиду что разработчики PVS выбрали Windows как целевую платформу, потому что под нее значительно больше коммерческого софта.
Это утверждение исходит из предпосылки что подавляющее большинство коммерческого софта как пишется, так и _собирается_ под Windows
Я вот тоже не знаю ответов, но предполагаю что заказчики PVS знают. И из того что они сделали версию только под студию я делаю вывод что они нацелились на подавляющую часть рынка.
>Я имею ввиду что разработчики PVS выбрали Windows как целевую платформу, потому что под нее значительно больше коммерческого софта.
Это утверждение исходит из предпосылки что подавляющее большинство коммерческого софта как пишется, так и _собирается_ под Windows
>Но какое количество? С виду может и много, а в процентах сколько?
Откуда же я знаю? :)
>И вы сюда точно не включаете кроссплатформенный софт?
А если и включаю — что это меняет? Он от этого ведь не перестаёт быть коммерческим :) И вижуал студией при этом собирается весьма вряд ли: какой смысл морочиться двумя билд-системами?
>Я вот тоже не знаю ответов, но предполагаю что заказчики PVS знают.
Знают? Хм… интересно, откуда? Я сам-то не знаю точно, сколько у нас в компании внутренних проектов, какое количество сторонних проектов используется и сколько кастомного софта было написано на заказ — а им-то откуда это известно? Всё, что они могут сделать — это оценить (т.е. прикинуть) и на основании этой оценки принять решение. Они это сделали — это их право, и я ни в коем случае не собираюсь это право оспаривать.
>Это утверждение исходит из предпосылки что подавляющее большинство коммерческого софта как пишется, так и _собирается_ под Windows
Простой пример: подавляющее большинство десктопов в мире в целом и в России в частности — под Windows. Маков в России ничтожно мало. Однако это не помешало компании ABBYY выпустить Lingvo под Mac. Зачем? Как же так? Ведь поддержка ещё одной платформы — это дополнительные затраты. А учитывая долю Маков, может показаться, что версия под Мак вообще не имеет смысла и будет убыточной по определению. Но это не так. Подавляющая доля затрат уже была вложена — сами словари, алгоритмы поиска, транскрипция, произношение и т.д. Единственные дополнительные затраты для Мак-версии — это гуй-морда, дополнительное тестирование на целевой платформе и сопровождение (которое, опять же, по большей части «кросс-платформенно»). Так что затраты на поддержку дополнительной платформы составляют лишь малый процент от общих затрат, который окупится даже при том, что доля целевой платформы в России находится в районе 1.5%.
*поправляя пенсне* Таким образом, поддержка дополнительной платформы (даже той, которая занимает много меньшую долю рынка, чем основная) вполне может быть выгодна (в зависимости от распределения затрат).
Случай PVS-Studio в части распределения затрат очень похож на случай Lingvo: алгоритмы анализа, как Вы сами понимаете, имеют подавляющий вес в сравнении со всем остальным.
Откуда же я знаю? :)
>И вы сюда точно не включаете кроссплатформенный софт?
А если и включаю — что это меняет? Он от этого ведь не перестаёт быть коммерческим :) И вижуал студией при этом собирается весьма вряд ли: какой смысл морочиться двумя билд-системами?
>Я вот тоже не знаю ответов, но предполагаю что заказчики PVS знают.
Знают? Хм… интересно, откуда? Я сам-то не знаю точно, сколько у нас в компании внутренних проектов, какое количество сторонних проектов используется и сколько кастомного софта было написано на заказ — а им-то откуда это известно? Всё, что они могут сделать — это оценить (т.е. прикинуть) и на основании этой оценки принять решение. Они это сделали — это их право, и я ни в коем случае не собираюсь это право оспаривать.
>Это утверждение исходит из предпосылки что подавляющее большинство коммерческого софта как пишется, так и _собирается_ под Windows
Простой пример: подавляющее большинство десктопов в мире в целом и в России в частности — под Windows. Маков в России ничтожно мало. Однако это не помешало компании ABBYY выпустить Lingvo под Mac. Зачем? Как же так? Ведь поддержка ещё одной платформы — это дополнительные затраты. А учитывая долю Маков, может показаться, что версия под Мак вообще не имеет смысла и будет убыточной по определению. Но это не так. Подавляющая доля затрат уже была вложена — сами словари, алгоритмы поиска, транскрипция, произношение и т.д. Единственные дополнительные затраты для Мак-версии — это гуй-морда, дополнительное тестирование на целевой платформе и сопровождение (которое, опять же, по большей части «кросс-платформенно»). Так что затраты на поддержку дополнительной платформы составляют лишь малый процент от общих затрат, который окупится даже при том, что доля целевой платформы в России находится в районе 1.5%.
*поправляя пенсне* Таким образом, поддержка дополнительной платформы (даже той, которая занимает много меньшую долю рынка, чем основная) вполне может быть выгодна (в зависимости от распределения затрат).
Случай PVS-Studio в части распределения затрат очень похож на случай Lingvo: алгоритмы анализа, как Вы сами понимаете, имеют подавляющий вес в сравнении со всем остальным.
Э, ну вы сравнили словари (в англ вики написано 5 000 000 пользователей, не знаю на самом деле как) и анализатор кода С++ :)
Я не понимаю о чем мы спорим. Я пытаюсь до вас донести что в любой задаче ресурсы ограниченны и чем-то приходится жертвовать. В данном случае пожертвовали всеми платформами кроме Windows, и я пытаюсь вам растолковать почему они так сделали по моему мнению.
Я не понимаю о чем мы спорим. Я пытаюсь до вас донести что в любой задаче ресурсы ограниченны и чем-то приходится жертвовать. В данном случае пожертвовали всеми платформами кроме Windows, и я пытаюсь вам растолковать почему они так сделали по моему мнению.
А я вот утверждаю, что жертвы тут на самом деле минимальные ибо софт очень мало зависит от платформы, на самом деле. И еще скажу, что если эти самые жертвы изначально закладывать, то вы их даже и не заметите. 95 процентов тестов наверняка тоже не зависят от платформы. В сравнении с тем, что утилита заточена под анализ весьма узкой категории ошибок, которые просто оказались широко распространены среди вин разработчиков это вообще ничто!
То есть сделать приблуду для Linux'ового build сервера имхо особого труда не составит. Только вот ошибки в кроссплатформенном софте анализатор видеть не будет.
То есть сделать приблуду для Linux'ового build сервера имхо особого труда не составит. Только вот ошибки в кроссплатформенном софте анализатор видеть не будет.
>Э, ну вы сравнили словари (в англ вики написано 5 000 000 пользователей, не знаю на самом деле как) и анализатор кода С++ :)
А цену конечного продукта Вы не хотите учесть? Она тоже как бы слегка различается. Так, примерно на пару порядков.
>Я не понимаю о чем мы спорим.
Я тоже не понимаю. Я — о том, что малораспространённость платформы ещё не означает, что её поддержка убыточна. А Вы о чём?
>Я пытаюсь до вас донести что в любой задаче ресурсы ограниченны и чем-то приходится жертвовать.
Компания ABBYY тоже могла так рассуждать, и тогда версия Lingvo для Мака не появилась бы. Компания, несомненно, продолжала бы зарабатывать свои X денег. Но благодаря тому, что компания привлекла дополнительные ресурсы, она начала зарабатывать Y денег (Y > X). Вот и весь расклад.
А цену конечного продукта Вы не хотите учесть? Она тоже как бы слегка различается. Так, примерно на пару порядков.
>Я не понимаю о чем мы спорим.
Я тоже не понимаю. Я — о том, что малораспространённость платформы ещё не означает, что её поддержка убыточна. А Вы о чём?
>Я пытаюсь до вас донести что в любой задаче ресурсы ограниченны и чем-то приходится жертвовать.
Компания ABBYY тоже могла так рассуждать, и тогда версия Lingvo для Мака не появилась бы. Компания, несомненно, продолжала бы зарабатывать свои X денег. Но благодаря тому, что компания привлекла дополнительные ресурсы, она начала зарабатывать Y денег (Y > X). Вот и весь расклад.
Я лично подобной вещью развлекаюсь и автобилды делать из Linux окружения в разы удобнее, чем из Windows, вся система просто идеально создана для автоматизации любой рутины: написал несколько простых скриптов, скормил их планировщику и всё. Дело в шляпе. Я даже молчу про то, что код раза в 2 быстрее компилится, чем в Windows'е. Сказывается очень дешевое, в отличии от Windows порождение процессов.
Ну и разумеется для автобилдов можно любой имеющийся сервак взять и использовать, а не держать специальную windows машину.
Вообще по-моему мнению их анализатор заточен скорее под мешанину называемую «Си с классами», на которой так любят писать Виндовс софт, она к C++ весьма опосредованое значение имеет.
Тот же qutIM, который на C++/Qt написан оказался анализатору просто не по зубам: он не нашел ни единой ошибки ни в самом коде ни в сторонних библиотеках, самая большая из которых, gloox, написана полностью используя возможности из std. Хотя ошибки там безусловно есть, ибо с тем же gloox'ом были проблемы в amd64 сборках по началу.
Ну и разумеется для автобилдов можно любой имеющийся сервак взять и использовать, а не держать специальную windows машину.
Вообще по-моему мнению их анализатор заточен скорее под мешанину называемую «Си с классами», на которой так любят писать Виндовс софт, она к C++ весьма опосредованое значение имеет.
Тот же qutIM, который на C++/Qt написан оказался анализатору просто не по зубам: он не нашел ни единой ошибки ни в самом коде ни в сторонних библиотеках, самая большая из которых, gloox, написана полностью используя возможности из std. Хотя ошибки там безусловно есть, ибо с тем же gloox'ом были проблемы в amd64 сборках по началу.
Вы собираете _Windows_ приложения под Linux? Именно приложения написанные под Windows, а не кроссплатформенные?
Кроссплатформенные, но среда вполне способна и windows only софт собирать, надо только cmake скрипт накидать. И вообще не вижу смысла при существующих возможностях win only софт писать.
Я видимо плохо мысли свои могу сформулировать, давайте тезисно, а вы опровергните неверные:
0. Мы хотим зарабатывать продавая анализатор кода С++
1. Подавляющая часть _коммерческого_ софта на С++ пишется под Windows
2. Подавляющая часть коммерческого софта на С++ пишется в VisualStudio
3. У нас ограничены ресурсы и время
По-моему из этих предпосылок (если они верные) следует единственный вывод что в отведенное время с отведенными ресурсами надо разрабатывать анализатор под Windows интегрированный со студией.
0. Мы хотим зарабатывать продавая анализатор кода С++
1. Подавляющая часть _коммерческого_ софта на С++ пишется под Windows
2. Подавляющая часть коммерческого софта на С++ пишется в VisualStudio
3. У нас ограничены ресурсы и время
По-моему из этих предпосылок (если они верные) следует единственный вывод что в отведенное время с отведенными ресурсами надо разрабатывать анализатор под Windows интегрированный со студией.
Всему своё время. И оно пришло: PVS-Studio для Linux.
Вам нужна версия PVS-Studio под какую-то конкретную ОС? Пишите, обсудим варианты.
Мне интересна именно бесплатная версия, общего назначения, про которую речь. Но попробовать ее у меня нет возможности.
Неправда, есть возможность. Скачайте trial Visual Studio с сайта Microsoft.
А виндос, мне тоже скачать с их сайта и заодно портировать десятки тысяч строк кода под windows, заодно закупивь около тысячи лицензий на их windows-сервер, поставив везде их серверное ПО тоже.
А в группе «Peer-to-Peer» Вы тоже состоите из-за «закупить около тысячи лицензий»?
Кто хочет — ищет возможности, кто не хочет — ищет причины.
Кто хочет — ищет возможности, кто не хочет — ищет причины.
Не совсем понял суть вашего вопроса про группу peer-to-peer. Конкретно мне бы было интересно на конкретном проекте посмотреть, что скажет ваш анализатор кода, но проверить это я не имею возможности, по уже описанным причинам. Проверять на каких то надуманных примерах, я конечно, могу, но смысла особого в этом нет. Так же, например, я гоняю свои проекты под валгриндом, гугловой тулзой, основанной на валгринде для поиска гонок, пробую разные компиляторы, какие подходят. И соответственно есть желание попробовать данный продукт, но нет возможности. А портировать десятки тысяч строк, чтобы проанализировать код, довольно странно.
Да, Вам пришлось немного подождать, но вот: Как использовать PVS-Studio бесплатно.
это нормально что
при запуске
C:\src\OmniSample\OmniSample>«C:\Program Files\PVS-Studio\x86\PVS-Studio.exe»
я получаю
Cannot open configuration file PVS-Studio.cfg
при запуске
C:\src\OmniSample\OmniSample>«C:\Program Files\PVS-Studio\x86\PVS-Studio.exe»
я получаю
Cannot open configuration file PVS-Studio.cfg
Похоже на ошибку. Только не понятно, что за символы ">«"?
Откройте один файл какой-нибудь из OmniSample и сделайте ему «Check Current File». Отработало? Если нет, полный путь до этого файла скажите и сообщение.
Откройте один файл какой-нибудь из OmniSample и сделайте ему «Check Current File». Отработало? Если нет, полный путь до этого файла скажите и сообщение.
я пытаюсь из командной строки…
то победил прочитав www.viva64.com/ru/d/0007/#ID0EX4BG
дальше сделал cfg файл
OmniSample.cpp.PVS-Studio.cfg
input-file = C:\src\OmniSample\OmniSample\OmniSample.cpp.i
display-file-name = C:\src\OmniSample\OmniSample\OmniSample.cpp
new-output-format=no
show-all-err-in-string=yes
compile-as-c-code=no
openmp-disabled=yes
analysis-mode=1
timeout=200
data-model=0
disable-template-instantiation=yes
safe-types-filename=C:\src\OmniSample\OmniSample\safe_types.txt
vcprojectdir=C:\src\OmniSample\OmniSample\
vcinstalldir=C:\Program Files\PVS-Studio\x86\PVS-Studio.exe
platform-name=x86
после выполнения
C:\src\OmniSample\OmniSample>\PVS-Studio\x86\PVS-Studio.exe" --cfg C:\src\OmniSample OmniSample\OmniSample.cpp.PVS-Studio.cfg
получаю
"«C:\Program Files\PVS-Studio\x86\PVS-Studio.exevcvarsall.bat»" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
Системе не удается найти указанный путь.
в этом же каталоге есть файл
OmniSample.cpp.cl.cmd
@call «C:\Program Files\PVS-Studio\x86\PVS-Studio.exevcvarsall.bat» x86 >nul
@call «C:\Program Files\PVS-Studio\x86\PVS-Studio.exebin\cl.exe» @«C:\src\OmniSample\OmniSample\OmniSample.cpp.cl.cfg» 2>&1
куда дальше копать не понял
то победил прочитав www.viva64.com/ru/d/0007/#ID0EX4BG
дальше сделал cfg файл
OmniSample.cpp.PVS-Studio.cfg
input-file = C:\src\OmniSample\OmniSample\OmniSample.cpp.i
display-file-name = C:\src\OmniSample\OmniSample\OmniSample.cpp
new-output-format=no
show-all-err-in-string=yes
compile-as-c-code=no
openmp-disabled=yes
analysis-mode=1
timeout=200
data-model=0
disable-template-instantiation=yes
safe-types-filename=C:\src\OmniSample\OmniSample\safe_types.txt
vcprojectdir=C:\src\OmniSample\OmniSample\
vcinstalldir=C:\Program Files\PVS-Studio\x86\PVS-Studio.exe
platform-name=x86
после выполнения
C:\src\OmniSample\OmniSample>\PVS-Studio\x86\PVS-Studio.exe" --cfg C:\src\OmniSample OmniSample\OmniSample.cpp.PVS-Studio.cfg
получаю
"«C:\Program Files\PVS-Studio\x86\PVS-Studio.exevcvarsall.bat»" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
Системе не удается найти указанный путь.
в этом же каталоге есть файл
OmniSample.cpp.cl.cmd
@call «C:\Program Files\PVS-Studio\x86\PVS-Studio.exevcvarsall.bat» x86 >nul
@call «C:\Program Files\PVS-Studio\x86\PVS-Studio.exebin\cl.exe» @«C:\src\OmniSample\OmniSample\OmniSample.cpp.cl.cfg» 2>&1
куда дальше копать не понял
По поводу /* make compiler happy */ я тоже долго сомневался, почему бы не написать
(void)opaque;
вместо
if (opaque) items += size — size;
Более сакрального смысла, чем избавиться от предупреждения о неиспользованном параметре, я не вижу.
Так что PVS молодец и в этом случае.
(void)opaque;
вместо
if (opaque) items += size — size;
Более сакрального смысла, чем избавиться от предупреждения о неиспользованном параметре, я не вижу.
Так что PVS молодец и в этом случае.
Насчет empty() хороший показательный пример ошибки дизайна API, когда даже пара букв ведут к появлению ошибок. Сделали бы isEmty() и не все было бы окей.
а теперь по-русски: empty() — плохо, isEmpty() — хорошо
А std::remove(), который ничего не удаляет — вообще кошмар.
Хорошо, что есть способ автоматически это обнаружить :-)
Проверил на нескольких своих поделках…
1. Вот из эстетических соображений в солюшене студии у меня созданы папочки и уже в них проекты, в которых все исходники опять же по папочкам (Filter в терминах студии). Это выбило Ваш анализатор с фразой «Files with C or C++ source code for analysis not found».
2. Из-за п.1 пришлось .cpp файлы анализировать по одному, и немного странно показал себя триальный вариант ограничения доступа. Одна и та же ошибка, очевидно из разных #include "", может как нормально отобразиться, а может «прикрыться» TRIAL RESTRUCTION. Повторный анализ меняет «прикрытые» участки местами" :) Добавьте функцию запоминания, а то половина триальных ограничений обходится без каких-либо телодвижений.
3. для перегруженных функций класса множество «ошибок» вида It is odd that the '<=' function is fully equivalent to the '>' function, да эквивалентно, возможно я отстал от жизни но разве компилятор подставит (a > b) вместо (a <= b)?
4. Исходники класса реализующего алгоритм md5 просто свели анализатор с ума своими magic number :)
5. на код вида
ругается только на последнюю строку как на magic number.
Хотя я тут сам затруднюсь что-либо подсказать, по сути код не опасный, но и просто реагировать только на четверку тоже не хорошо, тогда надо и на остальные варианты указать, или не реагировать вообще.
Но вообще удобно, спасибо за хороший инструмент, нашел пару мест, где size_t тип суммируется с uint32_t или uint32_t используется в качестве индекса доступа к элементу std::string (функция .at() ), которые как-то пропустил, хотя вероятнее из-за того, что в процессе переработки просто сменился тип переменной.
1. Вот из эстетических соображений в солюшене студии у меня созданы папочки и уже в них проекты, в которых все исходники опять же по папочкам (Filter в терминах студии). Это выбило Ваш анализатор с фразой «Files with C or C++ source code for analysis not found».
2. Из-за п.1 пришлось .cpp файлы анализировать по одному, и немного странно показал себя триальный вариант ограничения доступа. Одна и та же ошибка, очевидно из разных #include "", может как нормально отобразиться, а может «прикрыться» TRIAL RESTRUCTION. Повторный анализ меняет «прикрытые» участки местами" :) Добавьте функцию запоминания, а то половина триальных ограничений обходится без каких-либо телодвижений.
3. для перегруженных функций класса множество «ошибок» вида It is odd that the '<=' function is fully equivalent to the '>' function, да эквивалентно, возможно я отстал от жизни но разве компилятор подставит (a > b) вместо (a <= b)?
4. Исходники класса реализующего алгоритм md5 просто свели анализатор с ума своими magic number :)
5. на код вида
return 1;
...
return 2;
...
return 4;ругается только на последнюю строку как на magic number.
Хотя я тут сам затруднюсь что-либо подсказать, по сути код не опасный, но и просто реагировать только на четверку тоже не хорошо, тогда надо и на остальные варианты указать, или не реагировать вообще.
Но вообще удобно, спасибо за хороший инструмент, нашел пару мест, где size_t тип суммируется с uint32_t или uint32_t используется в качестве индекса доступа к элементу std::string (функция .at() ), которые как-то пропустил, хотя вероятнее из-за того, что в процессе переработки просто сменился тип переменной.
1. Ошибка. Прошу, если это возможно, прислать файл проекта и файл солюшена (*.vcproj, *.sln).
2. Смысла нет. Кто жадный, тот всё равно не купит.
3. Имеется в виду, что эквивалентно ТЕЛО функций. Т.е. одну функцию можно реализовать через другую. Посмотрите пример в документации.
4. Можно отключить правило или добавить библиотеку в исключения.
5. Это правило относится к 64-битности. С точки зрения 64-битного кода константы 1 и 2 подозрения не вызывают.
Спасибо за внимание к инструменту.
2. Смысла нет. Кто жадный, тот всё равно не купит.
3. Имеется в виду, что эквивалентно ТЕЛО функций. Т.е. одну функцию можно реализовать через другую. Посмотрите пример в документации.
4. Можно отключить правило или добавить библиотеку в исключения.
5. Это правило относится к 64-битности. С точки зрения 64-битного кода константы 1 и 2 подозрения не вызывают.
Спасибо за внимание к инструменту.
1. Отправил
3. Да, тело функции одинаковое (вызов внутренней функции сравнения), но может имеет смысл выделить анализ перегруженных операторов? Но тут вопрос гибкости анализатора конечно.
3. Да, тело функции одинаковое (вызов внутренней функции сравнения), но может имеет смысл выделить анализ перегруженных операторов? Но тут вопрос гибкости анализатора конечно.
Возможно следует. Приведите, пожалуйста, фрамент кода.
// template of string class
template <typename _Tp>
class _template_string_t
{
...
// compare two stings
friend FUNCTION_( ptrdiff_t ) _compare (
const _template_string_t< type_t > &str1,
const _template_string_t< type_t > &str2
)
{
...
}
...
//
friend FUNCTION_( _template_string_t< type_t > ) operator > (
const _template_string_t< type_t > &str1,
const _template_string_t< type_t > &str2
)
{
return ( _compare( str1, str2 ) > 0 );
}
//----------------------------------------------------------------------
//
friend FUNCTION_( _template_string_t< type_t > ) operator < (
const _template_string_t< type_t > &str1,
const _template_string_t< type_t > &str2
)
{
return ( _compare( str1, str2 ) < 0 );
}
//----------------------------------------------------------------------
//
friend FUNCTION_( _template_string_t< type_t > ) operator >= (
const _template_string_t< type_t > &str1,
const _template_string_t< type_t > &str2
)
{
return ( _compare( str1, str2 ) < 0 );
}
//----------------------------------------------------------------------
//
friend FUNCTION_( _template_string_t< type_t > ) operator <= (
const _template_string_t< type_t > &str1,
const _template_string_t< type_t > &str2
)
{
return ( _compare( str1, str2 ) > 0 );
}
//----------------------------------------------------------------------это домашняя поделка 'just for fun', тело операторов действительно одинаковое, но заменять (a <= b) на (a > b) компилятор вроде еще не умеет и для корректного поведения требуется перегрузить оба оператора, а PVS выводит это в предупреждения, что мне лично кажется не корректным.
Видимо время позднее, и я что-то не могу сообразить, а почему функция < и >= должны быть одинаковыми?
friend FUNCTION_( _template_string_t< type_t > ) operator < (
const _template_string_t< type_t > &str1,
const _template_string_t< type_t > &str2
)
{
return ( _compare( str1, str2 ) < 0 );
}
friend FUNCTION_( _template_string_t< type_t > ) operator >= (
const _template_string_t< type_t > &str1,
const _template_string_t< type_t > &str2
)
{
return ( _compare( str1, str2 ) < 0 );
}
Время действительно позднее было. Тут целиком моя ошибка.
Так как эта поделка не живет ни в одной SCM, и таскается с работы/домой/обратно на флешке, дома то я исправил ошибку, а на работе — нет.
В варианте >= должно быть так:
(оператор NOT — ! был пропущен)
Получился как раз очередной пример для демонстрации утилиты :)
А так как время позднее, то ЧСВ зашкалило и не позволило увидеть ошибку у себя (исправленную, но в другой версии).
Так как эта поделка не живет ни в одной SCM, и таскается с работы/домой/обратно на флешке, дома то я исправил ошибку, а на работе — нет.
В варианте >= должно быть так:
return !( _compare( str1, str2 ) < 0 );(оператор NOT — ! был пропущен)
Получился как раз очередной пример для демонстрации утилиты :)
А так как время позднее, то ЧСВ зашкалило и не позволило увидеть ошибку у себя (исправленную, но в другой версии).
Эх, хороший инструмент. Но для бесплатной Microsoft Visual Studio Express Edition не подходит, и привязка к микрософтовскому IDE сильно ограничивает область использования.
Интересно было сравнить с Purify, который стоит много денег, как известно.
У Вас есть Purify? Давайте вместе статью-сравнение сделаем?
К сожалению, на нынешней работе нет. На старой был.
Ну и как он? Нравился? Чем плох, чем хорош? Каков интерфейс? Удобно ли пользоваться? PVS-Studio по удобству лучше или нет?
Вещь суперская, ИМХО. Сама тулза консольная — пишет результат в логи. Но есть гуй для просмотра этих самых логов. Пользоваться удобно, если дружишь с консолью.
Позволяет искать утечки памяти, чтение/запись непроинициализированной памяти, выход за границы массива, попытки освобождения уже освобожденного участка памяти и т.п. При этом каждая ошибка сопровождается очень полезной информацией. Такой, как, например, для утечки памяти: колстэк до места, где выделилась память, адрес, её размер. Для чтения непроинициализированной памяти: колстэк до строчки, где произошла ошибка, адрес участка памяти, сколько байт пытаемся прочитать, сколько из них за пределами проинициализированного участка, колстэк до строчки, где был выделен проинизиализированный «кусочек» памяти.
PVS-Studio никогда не использовал, поэтому ничего не могу касательно неё сказать.
Позволяет искать утечки памяти, чтение/запись непроинициализированной памяти, выход за границы массива, попытки освобождения уже освобожденного участка памяти и т.п. При этом каждая ошибка сопровождается очень полезной информацией. Такой, как, например, для утечки памяти: колстэк до места, где выделилась память, адрес, её размер. Для чтения непроинициализированной памяти: колстэк до строчки, где произошла ошибка, адрес участка памяти, сколько байт пытаемся прочитать, сколько из них за пределами проинициализированного участка, колстэк до строчки, где был выделен проинизиализированный «кусочек» памяти.
PVS-Studio никогда не использовал, поэтому ничего не могу касательно неё сказать.
Не удается скачать files.viva64.com/PVS-Studio_setup.exe
пользуюсь интеловским анализатором, переходить на какой-то другой охоты нет.
Запустил таки :)
V003. Unrecognized error found на куче файлов на строчке #include «stdafx.h»
Пока анализ продолжается, по оценке он займет 3-4часа.
V003. Unrecognized error found на куче файлов на строчке #include «stdafx.h»
Пока анализ продолжается, по оценке он займет 3-4часа.
А без встраивания в среду Visual Studio можно использовать? Например, для анализа кода для GCC или других произвольных компиляторов C/C++?
void handler( const boost::system::error_code& e )
{
printf( "%s\n", e.message().c_str() );
}
Call function 'printf' with variable number of arguments. Second argument has memsize type.
w00t?
{
printf( "%s\n", e.message().c_str() );
}
Call function 'printf' with variable number of arguments. Second argument has memsize type.
w00t?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Трепещи, мир! Мы выпустили PVS-Studio 4.00 с бесплатным анализатором общего назначения