Comments 47
UFO just landed and posted this here
Это лёгкий, дешёвый и быстрый статический анализатор Си/Си++ кода.
Если учесть, что придётся покупать Windows и полновесную Visual Studio, то не такой уж дешёвый.
А что бы разрабатывать под iOS потребуется купить Mac, хотя сам инструментарий, если мне не изменяет память, вообще бесплатен. Так что же? Не считать его бесплатным из-за цены среды? А ещё можно и стоимость компьютера приплюсовать, что уж мелочиться…
А если совсем не мелочиться — то можно ещё и стоимость электроэнергии включить. А тут на помощь приходит Linux с педальным приводом — и фитнес, и за электричество платить не надо!)
А что бы разрабатывать под iOS потребуется купить Mac
Не пояснишь, причём здесь iOS?
Речь ведь идёт об инструменте для С++программистов.
А не все из них используют:
1) Windows
2) Visual Studio (не Express версия)
Называть продукт сам по себе дешёвым можно сколько угодно. Главное не строить иллюзий, что потенциального покупателя от CppCat отделяет всего лишь его одна цена.
iOS — как самый наглядный пример. Того, что бесплатность или цена приложения не означает, что не придётся докупить какой-то «обвес». Они же не пытаются ввести в заблуждение, что с их продуктом можно работать без VS и Windows? Нет. Так какие претензии? Это скажем так, системные требования. У любого продукта есть системные требования.
Или вы хотите по каждому пункту сноски, как в рекламный компаниях?
«Это лёгкий*, дешёвый** и быстрый*** статический анализатор Си/Си++ кода.»
* — для умеющих читать мануал
** — не забудьте про цену Windows, Visual Studio и печенек
*** — относительно YY и ZZ по версии независимых экспертов из студии LLL от 01.02.2013 по григорианскому календарю"
Так ведь можно до абсурда довести. «Красивейший шутер!*
* — при наличии у вас видеокарты не слабее GeForce 8800 GTS или аналогичной».
Или вы хотите по каждому пункту сноски, как в рекламный компаниях?
«Это лёгкий*, дешёвый** и быстрый*** статический анализатор Си/Си++ кода.»
* — для умеющих читать мануал
** — не забудьте про цену Windows, Visual Studio и печенек
*** — относительно YY и ZZ по версии независимых экспертов из студии LLL от 01.02.2013 по григорианскому календарю"
Так ведь можно до абсурда довести. «Красивейший шутер!*
* — при наличии у вас видеокарты не слабее GeForce 8800 GTS или аналогичной».
Они же не пытаются ввести в заблуждение
Так какие претензии?
Я вообще-то никого ни в чём и не обвинял.
Я просто написал замечание.
У любого продукта есть системные требования
CppCat это не «любой» продукт.
Его потенциальные пользователи — это те, кто уже программирует на С++.
Только не все они это делают с использованием Windows и Visual Studio.
Само собой авторам CppCat виднее.
Так ведь можно до абсурда довести
Можно. Только зачем?
А если учесть билеты на проезд до работы, то совсем в копечку выйдет
Оу, а никто не встречал таких анализаторов кода к Code Composer Studio или Eclipse?
А не планируется кстати Standalone версия CppCat с поддержкой препроцессора gcc? Покупка полновесной версии VS и да и обязательный перевод проекта на VS само по себе не самое дешевое решение, даже при дешевом анализаторе. Учитывая что старший брат всё это умеет, это кажется необоснованным усложнением жизни.
Мне одному кажется что они позаимствовали фирменный стиль Amazon в логотипе?
Вот смотрю на подобные вещи, и удивляюсь порой: как такое количество ошибок в проекте может не особо влиять на работу приложения? То есть система настолько сложная, что мелкие ошибки при работе в ней остаются незаметны.
UFO just landed and posted this here
Да какой HL2, вы на количество ошибок в TF2 посмотрите, его ведь каждую неделю-две обновляют… Некоторые ошибки года с 2011 остаются, многие совсем смешные, вроде отсутсвующей анимации модели в игре (т.е. анимация в файлах есть, но она просто не прикручена к модели) и тому подобного, которые уже рапортовали (и даже делали полные фиксы — возьми и скопируй) много раз, но так и не исправлены…
С интересном читаю ваши статьи и каждый раз думается: как же оно вообще работает ))
Что думаете о проверке CryEngine 3 SDK?
Кстати вот я заметил, что для видео и аудио есть протоколы транспортного уровня, а для игр как-то все слабо. Я понимаю что игры стандартизировать довольно сложно, ведь всякие бывают и у них разные требования к сети.
Но вот стало интересно даже и нашел в сети статью от корейских исследователей на тему ММО(ну а кто ж еще, как не корейцы этим будут заниматся :)).
В общем кому интересно читайте:
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.98.7687&rep=rep1&type=pdf
Но вот стало интересно даже и нашел в сети статью от корейских исследователей на тему ММО(ну а кто ж еще, как не корейцы этим будут заниматся :)).
В общем кому интересно читайте:
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.98.7687&rep=rep1&type=pdf
UFO just landed and posted this here
Ооо, Source, вы даже не представляете, как я хотел, чтобы вы сделали его обзор!
Не связывались с Valve, чтобы проверить ветку src_main?
Не связывались с Valve, чтобы проверить ветку src_main?
Быть может, теперь свяжемся.
Кстати, только что глазами напоролся вот на такой участок кода в Shader API (функция CShaderAPIDx8::PickMatrix):
Так что проверить им действительно не помешало бы.
int vx = viewport.m_nTopLeftX;
int vy = viewport.m_nTopLeftX;
int vwidth = viewport.m_nWidth;
int vheight = viewport.m_nHeight;
int vy = viewport.m_nTopLeftX;
Так что проверить им действительно не помешало бы.
Все думаю как сделать так чтобы программисты использовали статический анализатор кода постоянно.
В большинстве контор используется код ревью, если б интегрироваться в какую-нибудь тулзу (например CodeCollaborator или Crucible) для код ревью и автоматически в виде комментариев к строкам показывать для нового и измененного кода ошибки то было бы очешуенно.
Вижу это примерно как в GitHub сейчас в pull request билд сервер автоматически показывает результаты сборки, примерно также автоматически к строкам с варнингами от статического анализатора появлялся комментарий с ошибкой.
В большинстве контор используется код ревью, если б интегрироваться в какую-нибудь тулзу (например CodeCollaborator или Crucible) для код ревью и автоматически в виде комментариев к строкам показывать для нового и измененного кода ошибки то было бы очешуенно.
Вижу это примерно как в GitHub сейчас в pull request билд сервер автоматически показывает результаты сборки, примерно также автоматически к строкам с варнингами от статического анализатора появлялся комментарий с ошибкой.
CppCat имеет функцию — инкрементальный анализ. Вы пишите код, а анализатор после сборки проекта в фоне запускает анализ. Подробнее можно посмотреть в руководстве.
PVS-Studio помимо инкрементального анализа можно настроить для ночных запусков. Например, нам на почту каждый день приходит отчёт о самопроверке по ночам. См. документацию о разных режимах запуска.
PVS-Studio помимо инкрементального анализа можно настроить для ночных запусков. Например, нам на почту каждый день приходит отчёт о самопроверке по ночам. См. документацию о разных режимах запуска.
Эти фишки я знаю. Но в ревью это было б полезней.
Во первых, заставить некоторых людей исправлять хотя бы варнинги компилятора (не то что статического анализатора кода). Поэтому им нету смысла ставить статический анализатор на компьютер.
Во вторых, так как не все варнинги статического анализатора нужно устранять в прекомит ревью компетентные люди проконтролируют что они будут исправлены до попадания изменений в trunk/master. Можно к примеру сделать чтобы ревьюверы могли помечать варнинги анализатора как дефекты необходимые для исправления до коммита.
По моему с отчетами на почту мало чего решают. Не получается сделать чтобы все сами проверяли отчет и исправляли варнинги. Если нужно чтобы варнинги устранялись приходиться назначать ответственного человека, который будет раскидывать их по тем кто должен исправить и проверять в случае необходимости что их исправили (что очень неудобно сделать в отличие от ревью).
Было б круто если бы была возможность интегрировать PVS Studio так как я сказал в билдсервера для GitHub, такие как codebetter.com/ и travis-ci.org/. Чтобы одним из шагом сборки коммиты pull request'а анализровались на варнинги и добавлялись варнинги только для новых/измененых строк как комментарии в pull request.
Во первых, заставить некоторых людей исправлять хотя бы варнинги компилятора (не то что статического анализатора кода). Поэтому им нету смысла ставить статический анализатор на компьютер.
Во вторых, так как не все варнинги статического анализатора нужно устранять в прекомит ревью компетентные люди проконтролируют что они будут исправлены до попадания изменений в trunk/master. Можно к примеру сделать чтобы ревьюверы могли помечать варнинги анализатора как дефекты необходимые для исправления до коммита.
По моему с отчетами на почту мало чего решают. Не получается сделать чтобы все сами проверяли отчет и исправляли варнинги. Если нужно чтобы варнинги устранялись приходиться назначать ответственного человека, который будет раскидывать их по тем кто должен исправить и проверять в случае необходимости что их исправили (что очень неудобно сделать в отличие от ревью).
Было б круто если бы была возможность интегрировать PVS Studio так как я сказал в билдсервера для GitHub, такие как codebetter.com/ и travis-ci.org/. Чтобы одним из шагом сборки коммиты pull request'а анализровались на варнинги и добавлялись варнинги только для новых/измененых строк как комментарии в pull request.
Это все мечты. Вот к примеру в проекте 5Gb сторонних библиотек, а проект сам на пару гигабайт. Чтобы его СОБРАТЬ, нужно ОКРУЖЕНИЕ. Причем здесь github и прочее. Глупости это.
Я же предлагаю чтобы билдсервер запускал анализ и добавлял информацию о варнингах в ревью. У билдсервера сто пудово есть ОКРУЖЕНИЕ.
Для пробы идеи в действие можно реализовать на основе pull request'ов github (как утилиты для codereview) + один из билдcерверов которые интегрируется с github, это проще всего реализовать. Интеграция с другими CodeReview утилитам думаю намного сложнее реализовать.
1. В buildserver добавляем шаг который будет анализировать только измененые файлы
2. Потом выдираем из логов PVS Studio только варнинги относительно изменных строк в pull request'е
3. С помощью API GitHub постим варнинги как комментарии к pull request'у.
Возьмем к примеру libgit2 github.com/libgit2/libgit2, каждый pull request к нему собирается в Travis travis-ci.org/libgit2/libgit2.
Вот так вот выглядит если pull requst прошел сборку github.com/libgit2/libgit2/pull/2051 (All is well — The Travis CI build passed). В эту же схему можно интегрировать, чтобы Travis добавлял варнинги статического анализатора кода в pull requst.
Для пробы идеи в действие можно реализовать на основе pull request'ов github (как утилиты для codereview) + один из билдcерверов которые интегрируется с github, это проще всего реализовать. Интеграция с другими CodeReview утилитам думаю намного сложнее реализовать.
1. В buildserver добавляем шаг который будет анализировать только измененые файлы
2. Потом выдираем из логов PVS Studio только варнинги относительно изменных строк в pull request'е
3. С помощью API GitHub постим варнинги как комментарии к pull request'у.
Возьмем к примеру libgit2 github.com/libgit2/libgit2, каждый pull request к нему собирается в Travis travis-ci.org/libgit2/libgit2.
Вот так вот выглядит если pull requst прошел сборку github.com/libgit2/libgit2/pull/2051 (All is well — The Travis CI build passed). В эту же схему можно интегрировать, чтобы Travis добавлял варнинги статического анализатора кода в pull requst.
PVS-Studio умеет сохранять лог в том числе и в текстовый файл. Хотите — к github прикрутите, хотите- к hubgit.
Я понимаю что можно это реализовать уже сейчас для github. Это были просто размышления как сделать варинги из статического анализатора кода полезней в реальной жизни :-)
Проблема только будет с другими утилитами для code review, не факт что там такое API есть.
Проблема только будет с другими утилитами для code review, не факт что там такое API есть.
Люди часто пишут глупости (я не про Вас, а вообще, раз уж упомянуто слово github) про то, что «а хорошо бы вы интегрировали свой софт с github» не понимая, что ЛЮБОЙ подобный инструмент интегрируется через экспорт отчета в текстовый файл. Который куда надо, туда и прикручивается на раз.
Но нет, надо модный github в комменте упомянуть обязательно :-). Авось лайкнут…
Но нет, надо модный github в комменте упомянуть обязательно :-). Авось лайкнут…
Быть может, как-то будет полезно вот это: "Использование внешних инструментов в PVS-Studio. Интеграция с системами отслеживания ошибок".
Плюс при покупке Site-лицензии готовы обсудить и реализовать нужные фичи для интеграции с чем-то.
Плюс при покупке Site-лицензии готовы обсудить и реализовать нужные фичи для интеграции с чем-то.
Steamworks SDK не думаете проверить? :)
PS: Steamworks доступен всем после входа через аккаунт Steam и принятия соглашения о конфиденциальности здесь. После принятия соглашения так же появляется доступ в группу Steamworks Development, в которой можно будет в том числе прокомментировать результаты. Ну и из мелких бонусов при вступлении возможен ранний доступ в некоторые бета-тестирования, как например сейчас происходит с In-Home Streaming — раздали доступ всем, кто находился на тот момент в этой группе.
PS: Steamworks доступен всем после входа через аккаунт Steam и принятия соглашения о конфиденциальности здесь. После принятия соглашения так же появляется доступ в группу Steamworks Development, в которой можно будет в том числе прокомментировать результаты. Ну и из мелких бонусов при вступлении возможен ранний доступ в некоторые бета-тестирования, как например сейчас происходит с In-Home Streaming — раздали доступ всем, кто находился на тот момент в этой группе.
ошибся топиком
Sign up to leave a comment.
Анализ проекта Source SDK