Comments 66
пора бы вам эту лошадку как логотип или талисман взять.
Кстати, интересно, откуда пошёл этот единорог, блюющий радугой.
Мне тут кстати ссылку вот такую прислали. Не удержался, и решил здесь её показать: www.youtube.com/watch?v=VHe0S22d1vQ :-)
Может, немного не в тему, но… У вас сборки анализатора для *nix есть? А то он судя по описанию вкусный, но на плюсах для Windows давно не пишу.
в фак не заглядывали?
Покажите мне ссылку на него на главной странице сайта в пределах видимости. Я его там не нашёл. Есть база знаний, но там никакой информации нет, равно как и на странице с триалом. Я посчитал, что в данном случае будет проще спросить непосредственно у автора статьи.
Согласен, сейчас быстро найти сложно. FAQ сейчас относится к документации. Ответ на поставленый вопрос.
Ясно. Тогда вопрос следующего характера. В GCC, насколько я понимаю, можно повыключать все не соответствующие стандарту функции, при этом от него не должны отвалиться заголовки (тот же хромиум, который вы ранее подвергали анализу, как-то же им собирается, правильно?). В таком случае, можно ли использовать каким-то образом анализатор под тем же вайном? Есть ли консольная версия для генерации отчёта в HTML?
Я не прошу портировать на *nix, меня интересует именно практическая возможность использования, пусть и с ограничениями на набор возможностей GCC.
Я не прошу портировать на *nix, меня интересует именно практическая возможность использования, пусть и с ограничениями на набор возможностей GCC.
Оно без VS пока даже ставиться отказывается (авторы говорят своего препроцессора в PVS ещё нет). Я сам для тех же целей хотел погонять тестовую версию PVS и обломался.
Нельзя. В том же FAQ написано почему:
В других компиляторах (например, GCC) есть также специфичные конструкции, которые надо будет поддержать. Это незаметный, но очень большой объем работ. То, что ключевое слово '__restrict' используется в 10 000 раз реже, чем 'for' вовсе не означает, что его можно не поддерживать. Многие программисты и не подозревают о таких вещах как __w64, __noop, __if_exists, __int3264, __uuidof, __based, __LPREFIX и так далее и так далее.
В других компиляторах (например, GCC) есть также специфичные конструкции, которые надо будет поддержать. Это незаметный, но очень большой объем работ. То, что ключевое слово '__restrict' используется в 10 000 раз реже, чем 'for' вовсе не означает, что его можно не поддерживать. Многие программисты и не подозревают о таких вещах как __w64, __noop, __if_exists, __int3264, __uuidof, __based, __LPREFIX и так далее и так далее.
Пост не читай@Сразу отвечай
В GCC, насколько я понимаю, можно повыключать все не соответствующие стандарту функцииЕсли их в коде не будет по той простой причине, что компилятору запрещено их использовать, то в чём проблема для PVS? При желании можно даже параллельно натравливать компилер от мелкомягких и ругаться на исходники, если он их не пережуёт.
gcc-specific есть в заголовочных файлах
А почему у меня интеловкий компилер их пережёвывает?
Потому, что он supports most GNU C and C++ language extensions?
То есть рекламируемое в посте «решение для разработки современных ресурсоёмких приложений» не совместимо с Intel C++ Compiler? Ооооок.
Всё смешалось, кони, люди. Предположим, есть проект для Visual Studio. Соответственно, в нем используются заголовочные файлы от Visual Studio. Мы поддерживаем Visual Studio специфик и значит можем проверить такой проект. А вот собирается он с помощью Visual C++ или с помощью интегрированного в VS компилятора Intel C++ нам не важно.
Другое дело, что когда мы в среде VS включаем Intel C++, плагин не можем работать таким проектом. Причина в том, что меняются классы для взаимодействия с проектом. Ведь добавляются новые опции т.п. То есть меняется API. И эти классы Intel практически не документированы. Но никто не мешает выставить режим «Использовать Си++» и спокойно проверить проект.
Другое дело, что когда мы в среде VS включаем Intel C++, плагин не можем работать таким проектом. Причина в том, что меняются классы для взаимодействия с проектом. Ведь добавляются новые опции т.п. То есть меняется API. И эти классы Intel практически не документированы. Но никто не мешает выставить режим «Использовать Си++» и спокойно проверить проект.
Intel поболее нас будет.
Документация -> Вопросы и ответы по PVS-Studio (PVS-Studio FAQ).
На тему PVS-Studio Standalone и Linux, возможно будет интересна вот эта новая заметка — "PVS-Studio теперь работает и без среды Visual Studio или C++Builder – проверяем препроцессированные файлы от чего угодно".
Какая штука! Скажите, а чем обусловлена такая цена? Очень трудно переубедить свою жабу купить плагин к VS за 3/4 зарплаты.
UFO just landed and posted this here
Ну вот вы сами и ответили, если этот продукт сэкономит компании 2.5 человеко-месяца разработчика в течении года-двух, то жабу убеждать не надо.
К тому же человеко месяцы разработчика обхоядтся компании дороже чем просто его зарплата: рабочее место, налоги, соц. пакеты…
К тому же человеко месяцы разработчика обхоядтся компании дороже чем просто его зарплата: рабочее место, налоги, соц. пакеты…
Как раз недавно писали про оценку пользы от статического анализа здесь.
>> Скажите, а чем обусловлена такая цена?
Стоимостью мерседесов и квартир в Москве. Очень хочется…
Стоимостью мерседесов и квартир в Москве. Очень хочется…
С лицензией на обновление major releases всего на 1 год это будет обходиться Вам в 6.25% всех доходов (или $133.3 ежемесячно). Не критично с з/п в $2400, но за МКАДом это дороговато.
Однако мерседесы за МКАДом не продают дешевле все-равно :-(.
Решение проблемы. :)
Сейчас мы победим Вашу Жабу! Прошу прощения, что для этого пришлось подождать пару лет. Вот он, убийца жаб:
Это наш новый статический анализатор CppCat для Visual C++ по цене $250.
Это наш новый статический анализатор CppCat для Visual C++ по цене $250.
За зарплату покупать не надо. Это B2B решение.
Для личного использования имеется бесплатный вариант лицензии: Как использовать PVS-Studio бесплатно.
Для личного использования имеется бесплатный вариант лицензии: Как использовать PVS-Studio бесплатно.
Ещё один новый вариант: Бесплатный PVS-Studio для тех, кто развивает открытые проекты.
Вы меня, конечно, извините, но статья относится к C++ на уровне «Потому что в Visual Studio можно писать на C++»
Если пиарите свой продукт, пиарьте в персональном блоге
Если пиарите свой продукт, пиарьте в персональном блоге
согласен. считаю, что с такими ценами на продукт, можно себе позволить на хабре корпоративный блог :)
Это реклама, а не PR.
“Наш продукт умеет вот такие полезные штуки. Купите, и жизнь станет лучше.” Где здесь PR?
Авторам: Когда планируете открыть сорцы для текущей версии?
“Наш продукт умеет вот такие полезные штуки. Купите, и жизнь станет лучше.” Где здесь PR?
Авторам: Когда планируете открыть сорцы для текущей версии?
> Авторам: Когда планируете открыть сорцы для текущей версии?
Попробуйте обосновать преимущества, которые мы от этого получим.
Попробуйте обосновать преимущества, которые мы от этого получим.
А вам зачем? Если есть идеи — welcome в e-mail.
(здесь было полотно)
Извините, посмотрел в ваши (с Andrey2008) профили и понял (учитывая тон комментария выше) что культура опенсорса вам совершенно чужда.
Мне — чтобы адаптировать под вариант языка gcc. Вам — тысячу раз обосновывали в Интернете. Если вы с преимуществами до сих пор не знакомы и бизнес-план заранее на открытие сорцов не рассчитан, то я ничего не изменю.
Извините, посмотрел в ваши (с Andrey2008) профили и понял (учитывая тон комментария выше) что культура опенсорса вам совершенно чужда.
Мне — чтобы адаптировать под вариант языка gcc. Вам — тысячу раз обосновывали в Интернете. Если вы с преимуществами до сих пор не знакомы и бизнес-план заранее на открытие сорцов не рассчитан, то я ничего не изменю.
«Мне — чтобы адаптировать под вариант языка gcc».
Это нерациональное желание. Поясню почему. Это большая и сложная задача. И сторонний человек с большой вероятностью вряд ли корректно с ней справится. В сложных открытых проектах что-то существенное, могут делать только те, кто постоянно этим занимаются. То есть ядро проекта. Все остальные — только по мелочи. К такому сложному проекту относится и статический анализатор кода. У меня даже есть доказательство. В своё время один человек делал парсер OpenC++. Потом этот проект ему стал не интересен и он выложил его в отрытом виде. Затем мы взяли этот проект и на основе него построили нашу библиотеку VivaCore. Так вот, когда мы более менее разобрались с внутренностями библиотеки OpenC++, мы выбросили все говноправки, которые вносили энтузиасты, чтобы поддержать например тип wchat_t и тому подобное. То есть это делал не автор библиотеки, а сторонние люди. Так вот, сделали они это не правильно.
Отсюда вывод. Адаптировать анализатор, например под GCC стороннему человеку можно. Но нужно понимать, что это потребует глубокого погружения в проект и много его времени. Намного больше времени, чем надо нам. Следовательно рациональнее, чтобы правки вносили мы сами. Цена решения этой задачи нами, ниже. Проще в конце концов дать нам денег и мы сделаем это. Это будет дешевле, чем сделать самому. Так вот я вновь спрашиваю: А вам зачем? Зачем Вам делать это самостоятельно? В чем смысл?
Это нерациональное желание. Поясню почему. Это большая и сложная задача. И сторонний человек с большой вероятностью вряд ли корректно с ней справится. В сложных открытых проектах что-то существенное, могут делать только те, кто постоянно этим занимаются. То есть ядро проекта. Все остальные — только по мелочи. К такому сложному проекту относится и статический анализатор кода. У меня даже есть доказательство. В своё время один человек делал парсер OpenC++. Потом этот проект ему стал не интересен и он выложил его в отрытом виде. Затем мы взяли этот проект и на основе него построили нашу библиотеку VivaCore. Так вот, когда мы более менее разобрались с внутренностями библиотеки OpenC++, мы выбросили все говноправки, которые вносили энтузиасты, чтобы поддержать например тип wchat_t и тому подобное. То есть это делал не автор библиотеки, а сторонние люди. Так вот, сделали они это не правильно.
Отсюда вывод. Адаптировать анализатор, например под GCC стороннему человеку можно. Но нужно понимать, что это потребует глубокого погружения в проект и много его времени. Намного больше времени, чем надо нам. Следовательно рациональнее, чтобы правки вносили мы сами. Цена решения этой задачи нами, ниже. Проще в конце концов дать нам денег и мы сделаем это. Это будет дешевле, чем сделать самому. Так вот я вновь спрашиваю: А вам зачем? Зачем Вам делать это самостоятельно? В чем смысл?
У Вас получились классные скриншоты — большие такие, с рамочкой и читабельным текстом. Приятно смотреть.
Штука хорошая, но 1600 евро за одну лицензю дороговато, если каждому в VS интегрировать. Может, интегрируемую версию подешевле сделаете?
Так Вы не дочитали страницу заказа видимо… Есть командная версия (на 5 человек) за 3500, а есть еще и Site License — там совсем недорого, если в пересчете на рабочее место.
Видимо 1600 было недостаточно дорого, потому решили сделать только за 3500 и ещё Site License, которая стоит настолько неприлично дорого, что сами постеснялись написать на странице покупок её цену. Жалко, что такие жадные стали так быстро, даже для нашего опенсорсного некоммерческого проекта Shareaza пожалели лицензию, а ведь раньше раздавали, для всяких шняжных DC++… *вздох*
Здравствуйте. Мы по прежнему предоставляем для открытых некоммерческих проектов бесплатную лицензию. По поводу Вас, мы не помним, чтобы Вы писали или просили. Прошу написать нам ещё раз. Иногда бывает, что контакты обрываются. Например, нам пишет человек и просит бесплатную лицензию. Мы спрашиваем, кто он. А он пропадает. Может просто наше письмо не доходит или в спам попадает…
Мы кстати и просто даём попробовать на некоторое время. Вот пример из свежего: "Review: PVS Studio". Стучите, и отворят вам! Пишите и ответят вам! :)
По поводу цены. Это не мы жадные. Это некоторые компании жадные. Странно, когда немаленькая компания покупает Single License, аргументируя, например это тем, что будет только одна установка. Установка эта на сервер (проверки будут ночные и естественно не для одного человека). Индивидуальному разработчику, конечно эта цена высока. Но мы готовы предоставлять им скидки. Пишите.
Мы кстати и просто даём попробовать на некоторое время. Вот пример из свежего: "Review: PVS Studio". Стучите, и отворят вам! Пишите и ответят вам! :)
По поводу цены. Это не мы жадные. Это некоторые компании жадные. Странно, когда немаленькая компания покупает Single License, аргументируя, например это тем, что будет только одна установка. Установка эта на сервер (проверки будут ночные и естественно не для одного человека). Индивидуальному разработчику, конечно эта цена высока. Но мы готовы предоставлять им скидки. Пишите.
Хорошо. Вы победили. Справедливость восстановлена. Приглашаю приобрести лицензию на наш новый программный продукт CppCat.
Это младший брат анализатора PVS-Studio. У него переработан интерфейс и удалена необязательная функциональность. И главное — его цена: $250.
Мы считаем, что 80% людей функционал CppCat будет достаточен. Тем, кому понадобится что-то большее или какие-то доработки — тем, как и раньше, предлагается «старший брат» — PVS-Studio.
Это младший брат анализатора PVS-Studio. У него переработан интерфейс и удалена необязательная функциональность. И главное — его цена: $250.
Мы считаем, что 80% людей функционал CppCat будет достаточен. Тем, кому понадобится что-то большее или какие-то доработки — тем, как и раньше, предлагается «старший брат» — PVS-Studio.
>Только в Visual Studio 2010 появился API, который позволяет узнать, какие файлы были изменены, и какие от них зависят.
А зачем это нужно? Чтобы делать make, а не build? Ерунда какая.
Я сейчас перешел на VS2010, но после того как увидел, что самый крохотный проект на MFC все равно плодит исполняемый exe файл размером более 1,5Мб — пришел в ужас. И не я один, полинтернета этим забито. Workaround есть, но кривой, нужно патчить исходники MFC, убирать глобальные переменные, которые никому не нужны, но которые приводят к пухлости исполняемого кода.
VS2005 или VS2008 делает это же в 200Кб. Справедливо для MFC static link.
А зачем это нужно? Чтобы делать make, а не build? Ерунда какая.
Я сейчас перешел на VS2010, но после того как увидел, что самый крохотный проект на MFC все равно плодит исполняемый exe файл размером более 1,5Мб — пришел в ужас. И не я один, полинтернета этим забито. Workaround есть, но кривой, нужно патчить исходники MFC, убирать глобальные переменные, которые никому не нужны, но которые приводят к пухлости исполняемого кода.
VS2005 или VS2008 делает это же в 200Кб. Справедливо для MFC static link.
Дался вам этот лишний мегабайт. То, что пустой проект занимает 1.5М вместо 200КБ совершенно не означает, что большой проект будет занимать 200МБ вместо 20.
Если в большом проекте 100 отдельных исполняемых файлов, то так и будет.
У меня, кстати, таких файлов сейчас 14. А теперь, видимо, придется сделать один с разными ключами запуска, чтобы исключить накладные расходы. Или же переходить на MFC dynamic link и тащить Microsoft Redistributable 2010 в установщике, чего очень не хочется.
У меня, кстати, таких файлов сейчас 14. А теперь, видимо, придется сделать один с разными ключами запуска, чтобы исключить накладные расходы. Или же переходить на MFC dynamic link и тащить Microsoft Redistributable 2010 в установщике, чего очень не хочется.
Вы писали «Статический анализ выполняется дольше компиляции».
Меня заинтересовало время анализа. Например при анализе проекта из 3-4 тысяч строк кода, на сколько время анализа превышает время компиляции?
P.s. у меня к сожалению под рукой нет cpp проекта такого размера, но вот вопрос относительно производительности" полного" анализа возник. Хотелось бы услышать в цифрах=)
Меня заинтересовало время анализа. Например при анализе проекта из 3-4 тысяч строк кода, на сколько время анализа превышает время компиляции?
P.s. у меня к сожалению под рукой нет cpp проекта такого размера, но вот вопрос относительно производительности" полного" анализа возник. Хотелось бы услышать в цифрах=)
О скорости анализа говорить дело не такое простое. Скорость зависит от того, где расположен проект (на сетевом диске, на HDD, на RAID-массиве), от того сколько ядер, от того, какие библиотеки используются. Например, существенное время отнимает разбор #include от таких библиотек как boost. Но я понимаю, что хочется всё таки узнать среднюю температуру по больнице. Отвечаю. У нас в тестовой базе 65 проектов. Это 16625 файлов, таких как *.cpp, *.c, *.h и так далее, общим объемом 360 мегабайт. Запуск регрессионных тестов занимает порядка 5 часов. Для тестирования используется 4 ядра.
Не разделяю вашего сарказма «средняя температура по больнице».
Да я согласен, что замерять скорость анализа сложно, но этот показатель очень важен, и о нем нужно говорить.
Я просто вхожу в команду, которая разрабатывает инструмент анализа качества кода, написанного на языке C#. Детали из-за NDA я не могу разглашать, но мы парсим сорцы, строим AST, считаем метрики, плюс у нас есть достаточно разухабистый слой анализа метаданных с внешних сборок (.dll).
И мы постоянно анализируем как влияет введение новой фичи на скорость анализа проекта (как в рамках одной тестовой конфигурации железа, так и на разных машинах), как растет время анализа при увеличение размера анализируемых проектов, какая при этом зависимость.
Возможно я некорректно задал вопрос, но я от вас пытался этих цифр добиться=) потому что мне интересно как обстаят с этим дела на других платформах
Да я согласен, что замерять скорость анализа сложно, но этот показатель очень важен, и о нем нужно говорить.
Я просто вхожу в команду, которая разрабатывает инструмент анализа качества кода, написанного на языке C#. Детали из-за NDA я не могу разглашать, но мы парсим сорцы, строим AST, считаем метрики, плюс у нас есть достаточно разухабистый слой анализа метаданных с внешних сборок (.dll).
И мы постоянно анализируем как влияет введение новой фичи на скорость анализа проекта (как в рамках одной тестовой конфигурации железа, так и на разных машинах), как растет время анализа при увеличение размера анализируемых проектов, какая при этом зависимость.
Возможно я некорректно задал вопрос, но я от вас пытался этих цифр добиться=) потому что мне интересно как обстаят с этим дела на других платформах
Согласен, что скорость анализа существенный показатель. Однако важным я его назвать воздержусь. Инструменты статического анализа хороши тем, что хорошо масштабируются. Запуски при желании можно легко распределять между ядрами и отдельными компьютерами. Это я к тому, что пытаюсь понять, в чем важность таких точных замеров?
А есть что-то подобное для Delphi?
Эх, почитал и порадовался, что в программах на Java нет большинства проблем, на поиск которых направлен PVS. Не сочтите за холивар, но увы, C++ не смотря на отсутствие конкурентов в некоторых областях, объективно не очень удачный язык. Хорошо хоть, что есть PVS. Писал бы на плюсах, обязательно приобрел бы.
> объективно не очень удачный язык
а вы можете предложить более удачный объектно-ориентированный кросс-платформенный язык программирования, компилируемый в бинарный код?
а вы можете предложить более удачный объектно-ориентированный кросс-платформенный язык программирования, компилируемый в бинарный код?
Common Lisp :P
C, Objective-C, D, Common Lisp (В порядке распространенности)
Но они не могут вытеснить С++, вы правы.
C не является объектно-ориентированным вроде бы.
Objective-С хоть и компилируется в бинарный код, но требует наличия рантайма. Бинарный код, я думаю, был упомянут с намёком на производительность, а в Objective-C посылка сообщений (AKA вызов методов) — намного более накладная штука, чем виртуальные вызовы в С++, не говоря уж об обычных, которые могут ещё и проинлайниться. Ну и охват платформ всё же намного меньше, чем у С++.
По поводу D и Common Lisp дискутировать не готов.
Objective-С хоть и компилируется в бинарный код, но требует наличия рантайма. Бинарный код, я думаю, был упомянут с намёком на производительность, а в Objective-C посылка сообщений (AKA вызов методов) — намного более накладная штука, чем виртуальные вызовы в С++, не говоря уж об обычных, которые могут ещё и проинлайниться. Ну и охват платформ всё же намного меньше, чем у С++.
По поводу D и Common Lisp дискутировать не готов.
Я согласен, что весомых конкурентов нету. Есть определенные недостатки. Но это не значит, что нельзя сделать нормальный типобезопасный кроссплатформенный компилируемый язык с богатыми возможностями. Просто некому взять на себя такую сложную задачу, так как все равно спрос не настолько велик, можно перебиться тем, что есть.
Да и я не зря написал про Java — достаточно быстрый язык, при этом компилятор и умный рантайм избавляют от большинства мутных ошибок.
Да и я не зря написал про Java — достаточно быстрый язык, при этом компилятор и умный рантайм избавляют от большинства мутных ошибок.
Извините за уже почти некропост, но на Common Lisp делают миллионы денег и десятки коммерческих проектов, на D — ни того ни другого. В порядке распространённости их следовало бы поменять местами.
Sign up to leave a comment.
PVS-Studio научился следить за тем, как вы программируете