Как 10 лет назад начинался проект PVS-Studio

    Единорог

    Десять лет назад мы создали простенькую утилиту под названием Viva64, предназначенную для выявления некоторых проблем в 64-битном коде. Так было заложено начало статического анализатора кода PVS-Studio. Хотя с того момента прошло 10 лет, что-то более-менее у нас, как у компании, стало получаться только несколько лет назад. Эта статья — не история успеха, так как мы считаем, что всё интересное только начинается. Однако, 10 лет — это повод подвести промежуточные итоги и рассказать нашим читателям как все начиналось, какие нас ждали ошибки, и что на данный момент у нас получилось. Местами я, возможно, буду не совсем хронологически точен при описании событий. Моя память не идеальна, а 10 лет — это длительный промежуток времени. Желаю всем приятного чтения.

    Предыстория


    Я (Андрей Карпов) и Евгений Рыжков работали в маленькой тульской компании, занимающейся созданием пакетов численного моделирования и визуализации данных. Работа была интересная и удавалось прикоснуться к передовым по тем временам технологиям. Например, работая с задачами по визуализации данных, мы экспериментировали с 3D очками, работающими по принципу поочередного закрытия глаз. Картинки выводились на ЭЛТ монитор, который показывал изображение то для левого, то для правого глаза. Думаю, мало кто видел такую древность: очки, подключенные к компьютеру по проводу, и ЭЛТ монитор, работающий в чересстрочном режиме (100 кадров в секунду), чтобы на каждый глаз приходилось хотя бы по 50 кадров. Выглядело, на самом деле, всё это ужасно, и моментально начинали болеть глаза, так что ничего удивительного, что широко эта технология не прижилась.

    Ещё, например, мы занимались самостоятельным изготовлением бюджетного кластера на основании обыкновенных материнских плат для компьютера. Использовались платы с двумя физическими AMD процессорами. Это сейчас никого не удивишь процессором с 8 ядрами. Тогда же в тульском магазине материнская плата с двумя ядрами — это было чудо чудное, диво дивное. Мы объединили 4 такие платы и получили 8-ядерный мини-кластер, на котором вели различные расчёты. Я непосредственно участвовал в пайке этого устройства:

    Рисунок 1. Собранный из подручных материалов мини-кластер. Характеристики: 8 процессоров, 16 гигабайт памяти.


    Рисунок 1. Собранный из подручных материалов мини-кластер. Характеристики: 8 процессоров, 16 гигабайт памяти.

    Получилось не совсем хорошо, так как не удалось как следует решить вопрос вентиляции и пришлось, пожертвовав красотой, снять задние крышки. Впрочем, со своими задачами кластер справлялся.

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

    В 2005 году вышла Visual Studio 2005, в которой стало возможным разрабатывать 64-битные программы для 64-битной архитектуры (в те времена она называлась AMD64). Помню ещё я ездил в Москву на конференцию компании Microsoft, где демонстрировали как теперь легко и просто можно перекомпилировать код под 64-битный процессор. В общем, 64-битность — это был новый важный тренд в развитии компьютеров.

    Конечно, и до этого были 64-битные микропроцессоры. Например, можно вспомнить тот же Itanium. Но именно появление AMD64 оказало существенное воздействие на IT-индустрию: появились 64-битные процессоры, доступные рядовому пользователю, а прикладные Windows-программисты получили возможность писать для этих процессоров программы в привычной среде разработки Visual C++.

    В задачах визуализации и численного моделирования большой объём памяти крайне важен. Поэтому, сразу с выходом Visual Studio 2005, мы начали работы по созданию 64-битных версий приложений.

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

    Компания Microsoft не обманула, нам действительно достаточно быстро удалось перекомпилировать свои приложения в режиме x64. На это ушло около 3-х недель. И как нам тогда казалось, мы получили 64-битный дистрибутив наших приложений.

    Ха! Вот только программы работали неправильно. Причем в их неправильной работе была какая-то подлость. Программы успешно проходили все внутренние тесты, корректно работали на тестовых данных. Но когда мы хотели воспользоваться всей мощью 64-битного приложения, начинались странные непонятные ошибки. Программа начинала глючить, когда выделяла более 10 гигабайт памяти для обработки больших наборов входных данных.

    Рисунок 2. У меня не сохранилось картинок, демонстрирующих ошибки визуализации в 64-битном приложении. Я не мог предположить, что через много лет они мне понадобятся. Но эта картинка очень похожа на результат ошибок, которые я наблюдал. Неожиданно могла отрисоваться только часть объекта.


    Рисунок 2. У меня не сохранилось картинок, демонстрирующих ошибки визуализации в 64-битном приложении. Я не мог предположить, что через много лет они мне понадобятся. Но эта картинка очень похожа на результат ошибок, которые я наблюдал. Неожиданно могла отрисоваться только часть объекта.

    Сейчас-то я знаю все те причины, которые приводили к такому странному поведению программ. Где-то указатель превращали в int, а потом обратно в указатель. Если указатель ссылался на объект в младших 4 гигабайтах памяти, то всё было хорошо. А вот если объект создавался за границей в 4 гигабайта, то проблемы были неизбежны.

    Были ошибки и в вычислениях вида:

    unsigned int X, Y, Z;
    Uint64 Q = X * Y * Z; 

    Хотя результат является 64-битной переменной, это не помогает. Переполнение возникает при перемножении 32-битных переменных.

    Естественно, есть и множество других способов отстрелить себе ногу. Подробнее со всеми этими бедами можно познакомиться вот здесь: "Коллекция примеров 64-битных ошибок в реальных программах".

    Тогда же, в 2005 году, происходящее с нашими программами выглядело непонятной магией. И самое главное, в тот момент мы не понимали, как нам найти и устранить дефекты. Все наши способы неожиданно нам отказали.

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

    Мы обратились к популярной тогда программе BoundsChecker, которая до этого не раз нам помогала. Вот только оказалось, что она ещё не умеет работать с 64-битными приложениями. Впрочем, если бы и работала, не думаю, что нам это сильно помогло. Скорость программы при использовании BoundsChecker замедляется в десятки раз. Думаю, для наших случаев это вылилось бы в дни ожидания.

    Мы поняли, что зашли тупик: знаем, что в программе есть ошибки, но не знаем, как их искать.

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

    От безысходности мы начали искать новые пути. Рассматривался вариант заменить все целочисленные типы на специальные классы, такие как SafeInt. Это позволило бы, по крайней мере, легко находить целочисленные переполнения. Однако, оказалось, что сделать это для существующих приложений весьма непросто.

    Потом мы познакомились с некоторыми инструментами статического анализа кода и даже купили Gimpel PC-Lint. Но этот анализатор почти ничем нам не помог. Он не был ориентирован на поиск 64-битных ошибок.

    И тут мы осознали последствия того, что мы первопроходцы. Мы столкнулись с 64-битными ошибками, для поиска которых мир ещё не предложил никаких решений.

    Как же мы вышли из положения? Мы решили прочитать код. Конечно, не весь. Мы настроили PC-Lint так, чтобы он выдавал предупреждения на все явные приведения типов, на неявное расширение int в 64-битные типы и так далее. Конечно, получилось невероятное количество бесполезных сообщений, но это всё равно лучше, чем просто читать весь код от начала до конца.

    Мы изучили потенциально опасные места, на которые, после специальной настройки, нам указывал PC-Lint. Полностью прочитали наиболее важные модули и фукнции. И вот, по прошествии несколько месяцев получили, наконец, стабильную версию 64-битных приложений.

    Как вы, возможно, догадались, задачей портирования на 64-битную систему занимались два человека: я и Евгений Рыжков.

    Выводы, которые мы тогда сделали:

    • с переходом на 64-битные системы люди будут сталкиваться в своём коде с 64-битными ошибками;
    • эти ошибки очень сложно искать;
    • нет никаких инструментов, помогающих находить такие ошибки.

    Приблизительно в это же время происходило другое судьбоносное событие. Евгений Рыжков увлекся чтением книг, посвящённых стартапам и новомодному направлению ISV (Independent software vendor). Впрочем, слова «стартап» тогда, кажется, ещё не было. Во всяком случае в том смысле, в котором есть сейчас.

    11 лет назад индустрия телефонов ещё не была развита, не существовало App Store и тому подобного. Если бы существовало, Евгений, возможно, занялся бы созданием игр для телефонов и планшетов. Тогда же он был ограничен обыкновенным компьютером. Он попробовал сделать приложение — раскраску для детей, и попробовал продавать. В целом, получилось всё реализовать и даже сделать несколько продаж, но, конечно, о каком-то успехе и доходах с этого начинания говорить не приходилось. Он начал искать новое применение своих сил.

    У меня тоже существовала предпринимательская жилка, и мне хотелось попробовать создать что-то своё. Однако, на тот момент все эти мысли были нечёткими и не находили какого-то реального воплощения. И тут Евгений предложил подумать о создании чего-то этакого, что покорит мир и сделает нас богатыми и известными. В общем заразил меня классической мечтой стартапера. И мы начали думать.

    Viva64 версии 1.0


    Итак, имеются:

    1. два человека, которые хотят организовать какой-то стартап;
    2. эти два человека знакомы с существованием проблемы поиска ошибок в 64-битных программах на языке С++.

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

    Вначале мы перебирали какие-то простые и понятные идеи. Сайты делать не хотелось. Хотелось создавать именно законченный программный продукт. Но вот что предложить миру – мы долго не понимали. Хотелось выбрать направление, в котором может быть реальный спрос, а не только абстрактная красивая идея.

    Через некоторое время мы всё-таки начали размышлять над инструментом поиска 64-битных ошибок в программах на языке C и C++. Для начала мы прикидывали, что именно это должно быть. Вначале мы думали над каким-то динамическим анализатором, типа BoundsChecker. Однако, это было слишком сложно, плюс было непонятно, как сделать поиск ошибок некоторых разновидностей.

    Постепенно нам стало понятно, что это должен быть статический анализатор кода. Т.е. программа, которая указывает программистам на участки кода, которые надо проверить. Следовало создать инструмент типа PC-Lint или Parasoft C++test, но только ориентированный на поиск специфичных типов ошибок.

    Важным вопросом было, посильно ли вообще нам сделать такой инструмент, все-таки речь шла о разборе С++ кода. Пришлось изучать и этот вопрос.

    Никакого LLVM в те времена не существовало, поэтому мы рассматривали вариант взять за основу компилятор GCC или какую-то из открытых бесплатных библиотек. Понятно, что ещё были платные библиотеки разбора C++ кода, но мы их даже не рассматривали. GCC нам показался слишком сложным и тяжеловесным, плюс было непонятно, можно ли на его основе как-то создать закрытое приложение. Открытое делать не хотелось, так как непонятно, как на нем заработать. В итоге выбор пал на малоизвестную библиотеку OpenC++. К этому моменту библиотека была заброшена, но нас это не остановило, тем более что она показалась весьма простой, и мы очень быстро смогли написать с её помощью простейшую пробную диагностику.

    И вот мы определились и решились, что будем делать инструмент поиска 64-битных ошибок в C/C++ коде. Фактически, это будет классический статический анализатор кода, но в то время мы старались не использовать эти слова. Нам казалось, что это только собьет с толку людей, которые будут искать в интернете «инструмент для поиска 64-битных ошибок».

    Имея опыт общения с Gimpel PC-Lint, мы сразу решили, что будем делать инструмент как плагин к Visual Studio. В те времена, чтобы использовать PC-Lint из Visual Studio, нужно было сплясать с бубном. Я даже написал потом небольшую заметку на эту тему, которая, кстати, пользовалась популярностью: Установка PC-Lint и его использование в Visual Studio 2005. В общем, мы считали, что подобная интеграция никуда не годится и надо сразу предоставить пользователям удобный интерфейс. Т.е. человек должен установить инструмент и сразу иметь возможность приступить к проверке проекта. Именно этому принципу наша команда следует до сих пор и считает его очень важным.

    В то время мы представляли себе Viva64 как простенькую утилиту, которую будем продавать всего за $200, но массово. Мы думали, что на этот инструмент должен резко появиться спрос в связи с глобальным переписыванием программ для 64-битных процессоров. План был такой: делаем простой инструмент, на который скоро будет большой спрос, продаём его года 3-4. Затем, заработав денег на этом гениальном предвидении, займемся каким-то другим проектом. В общем юношеские фантазии о том, какую крутую идею мы придумали и как быстро на ней поднимемся. Даже вот такой график нарисовали о том, как, на наш взгляд, должен выглядеть спрос:

    Рисунок 3. В 2006 году Евгений начертил вот такой график предполагаемой востребованности решения для проверки С++ кода на совместимость с платформой AMD64. Предполагалось, что в 2010 спрос пойдёт на убыль и, вдобавок, Microsoft выпустит какое-то стандартное решение, которое вытеснит анализатор Viva64 с рынка. Однако, за 2-3 года мы надеялись снять "сливки" и накопить денег для будущих начинаний.


    Рисунок 3. В 2006 году Евгений начертил вот такой график предполагаемой востребованности решения для проверки С++ кода на совместимость с платформой AMD64. Предполагалось, что в 2010 спрос пойдёт на убыль и, вдобавок, Microsoft выпустит какое-то стандартное решение, которое вытеснит анализатор Viva64 с рынка. Однако, за 2-3 года мы надеялись снять «сливки» и накопить денег для будущих начинаний.

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

    И вот состоялось знаковое событие: 31 декабря 2006 года мы выложили первый публичный релиз Viva64 версии 1.00 в интернете. Помню Евгений говорил мне, что выложить надо обязательно до нового года, чтобы в истории версий фигурировал 2006 год. Пользователям будет казаться, что инструмент существует уже хотя-бы год, и это будет придавать ему солидности. Сейчас, по прошествии длинного пути в 10 лет, все это выглядит наивным, но тогда всё это казалось очень важным.

    Бюджет создания первой версии анализатора и сайта составил 43200 рублей. Естественно, наше время и силы здесь не учтены. Это были дополнительные расходы. Чтобы легче было понять размер суммы, пересчитаем по курсу доллара тех времен и получим $1710. Можно сказать, что мы все сделали практически без трат.

    Начиная с 2007 года, мы начали пробовать продавать наш инструмент, постепенно его усовершенствуя. Работы прибавилось ещё больше. Помимо программирования на прежней работе и программирования анализатора, добавилась работа по продвижению Viva64 в среде программистов. Я и Евгений начали учиться писать статьи, общаться на форумах, пробовать какие-то варианты платной рекламы.

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

    А продажи всё не шли и не шли. Вернее, что-то чуть-чуть мы сумели продать, но столь мало, что про это даже нет смысла говорить. Мы даже не пробовали вывести деньги, скопившиеся на счету реселлера, так как они бы ничем нам не помогли.

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

    Мы искали какие-то варианты найти деньги, чтобы продолжить разработку и верили, что надо продержаться чуть-чуть и начнется рост спроса на наш инструмент. Я уже плохо помню наши хаотичные действия того времени. Помню, например, поход к Сергею Лисицыну в компанию AutomatedQA, офис разработки которой расположен в Туле. Мы пытались заинтересовать его нашими наработками. Но то, чем мы занимались, как-то ни у кого не встречало интереса. Хотя, возможно, мы просто стучались не в те двери или не умели рассказать о себе.

    Надо было что-то решать, так как проект Viva64 упрямо отказывался становиться успешным и прибыльным. Мы начали искать подработку в виде аутсорса. Мы брались за всё подряд, что попадалось под руку. Мы успели посотрудничать с компаниями Ingate и Intelsys. Затем мы приняли участие в большом проекте одной итальянской компании. Это была программа для зубных техников, занимающихся изготовлением зубных протезов. На компьютере проектировался зубной мост или коронка, затем специальный станок её вытачивал. Фактически, это была сильно специализированная CAD система. Пришлось вспоминать раздел математики, связанный с матрицами поворота и преобразованием изображений. А заодно узнать, что такое NURBS поверхности.

    Рисунок 4. Один из этапов работы с отсканированной челюстью для создания моста. Обратите внимание, что слева не хватает зубов, а по краям два зуба уже обточены, чтобы можно было проектировать мост, который на них будет крепиться.


    Рисунок 4. Один из этапов работы с отсканированной челюстью для создания моста. Обратите внимание, что слева не хватает зубов, а по краям два зуба уже обточены, чтобы можно было проектировать мост, который на них будет крепиться.

    Опять начались тяжелые трудовые дни. 8 часов надо посвятить работе над CAD системой, а затем ещё, на сколько хватит сил, заниматься усовершенствованием Viva64, сайта, что-то делать по продвижению. Конечно, теперь не надо было тратить время на поездки в офис, так как мы работали дома. Но ещё неизвестно, что тяжелее. Сидеть безвылазно целыми днями за компьютером очень тяжело. Но, видимо, только так что-то и получается сделать, если хочется вырваться из круговорота однотипных будней. Чтобы произошли изменения, надо начать работать ещё больше.

    Популярность проекта Viva64 постепенно росла, но крайне медленно. Мы начали понимать, что никакого быстрого старта не получилось. Но всё ещё наивно надеялись, что он возможен, ещё чуть-чуть и 64-битность начнёт массово волновать программистов.

    Забегая вперед скажу, что у темы 64-битнойсти так никогда и не было всплеска. Был очень медленный постепенный переход от 32-битных к 64-битным приложениям. Он идёт и сейчас. До сих пор некоторые клиенты выбирают PVS-Studio, исключительно из-за того, что в нём есть диагностики для выявления проблем, связанных с 64-битностью.

    Получается, что с 64-битностью мы одновременно и не ошиблись, и ошиблись. Мы не ошиблись в том смысле, что проблема миграции большой кодовой базы на 64-битную платформу действительно существует. За 10 лет мы продали немало лицензий Viva64, а потом и PVS-Studio для поиска 64-битных ошибок. Но мы ошиблись в оценке временных интервалов. Мы думали, что переход будет активно происходить 2-3 года, и ещё пару лет будет спад. И, исходя именно из этих соображений, начинали проект. Мы рассчитывали на спринт, а ввязались в марафон, в котором участвуем вот уже 10 лет.

    Однако, это сейчас мы понимаем, что к чему. В то время мы продолжали верить в «64-битную тему» и занимались развитием анализатора.

    Старт 2008, точка невозврата


    И вот, в 2008 году судьба нас привела к государственной программе Старт. Вернее, готовиться мы к ней начали в 2007 году, а финансирование получили в 2008. В двух словах расскажу, что это такое. Цитата с сайта:

    «Цель Программы — содействие инноваторам, стремящимся разработать и освоить производство нового товара, изделия, технологии или услуги с использованием результатов своих научно-технологических исследований, находящихся на начальной стадии развития и имеющих большой потенциал коммерциализации. Следует иметь в виду, что программа „Старт“ в первую очередь ориентирована на инициативных научных работников, желающих на основе своих инновационных идей создать устойчиво работающий бизнес».

    Если совсем простыми словами, то дело обстоит так: вы рассказываете об инновационном проекте. Вам дают грант на его осуществление и проверяют, что вы достигаете заявленных результатов. Если все хорошо, то финансирование может быть продлено на второй, а затем третий год. Кстати, программа действует и сейчас.

    У нас осталось двойственное чувство от участия в этой программе. С одной стороны, она слишком бюрократизирована и требует соблюдения множества формальностей. С другой стороны, эта программа стимулирует перейти на новый уровень. В целом, я дам положительную оценку этой задумке. Участие в этой программе дало своего рода пинок нам под зад по многим направлениям.

    Для участия в программе требуется создать ООО. Далее, выделяются небольшие деньги (тогда это было 750 000 рублей на год). Но даже эти деньги потратить не так легко. Нельзя просто взять и накупить, например, компьютеров и рекламных баннеров на сайтах. А не потратить нельзя, да и глупо. В результате, необходимость что-то делать с деньгами привела к тому, что мы сняли первый офис. У нас появилось два первых сотрудника. Было куплено для офиса что-то из мебели и так далее.

    Рисунок 5. ООО "СиПроВер", 2008 год. Первый день в первом собственном офисе.


    Рисунок 5. ООО «СиПроВер», 2008 год. Первый день в первом собственном офисе.

    Итого, участие в программе Старт заставило нас выйти из дома и начать не играть в проект Viva64, а реально им заниматься. Старт подтолкнул нас к регистрации ООО, найму первых сотрудников, и вообще заставил чувствовать себя настоящими организаторами компании.

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

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

    Как я думаю, вы уже поняли: выделенные фондом деньги вовсе не покрыли все необходимые расходы. Мы по-прежнему занимались аутсорсом на «зубную тему», но теперь уже находясь в офисе. В очередной раз работы только прибавилось. Помимо аутсорса, развития анализатора, его продвижения, теперь добавилась работа с фондом: подготовка отчетов и поездки в Москву для их сдачи.

    Это был «Ад». И когда заканчивался 2008 год, мы решили, что не будем пытаться продлить наше участие в программе «Старт». Слишком много отнимает бюрократия, причем время и силы, которые мы на неё тратим, расходуются впустую. В это время начали потихоньку идти какие-то продажи Viva64, и мы видели, что явно уделяем проекту меньше сил, чем могли бы. Мы решили, что лучше затянем пояса, но зато будем больше заниматься перспективными направлениями, а не печатью талмудов отчётов. Мы не стали подавать заявку на следующий год. Со стороны такое решение, возможно, покажется глупым. Но я уверен, что тогда мы поступили правильно и, возможно, сэкономили себе 1 или 2 года.

    Я упомянул, что начались какие-то продажи Viva64. Да, именно так. Причем мы начали постепенно повышать цену, так как клиентами были крупные компании. Именно тогда закралось подозрение, что мы делаем продукт не для программистов, а для компаний. Впрочем, до осознания того, что мы B2B, было ещё далеко.

    VivaMP, первая ошибка


    За десять лет мы допустили множество ошибок. Про мелкие рассказывать я не буду, так как это, во-первых, не очень интересно, а, во-вторых, я уже почти всё позабыл. В качестве примера такого мелкого ляпа могу вспомнить, что первый год наше ООО работало не по упрощенной системе налогообложения, а по общей. Мы не знали, что надо подать заявление о переводе на упрощенную систему в первые 5 дней — типичная ошибка новичков. Бедой это не было, так как в первый год ООО заработало мало денег, так что и потеряло тоже крайне мало.

    Так что давайте поговорим про более эпические ляпы. Первым из них стал проект VivaMP. Мы начали этот проект ещё в 2008 году, но первый релиз состоялся в марте 2009 года.

    Итак, мы уже смирились, что 64-бита не дали нам быстрого «взлёта», и начали искать новое направление, где можем опередить других. И как нам казалось — нашли.

    В 2008 году стали массово появляться многоядерные процессоры. На повестке дня программистов стоял вопрос: какая технология будет доминировать в сфере разработки параллельных программ на языке C и C++? Варианты были разные: MPI, OpenMP, какие-то уже существующие библиотеки, или которые могли вскоре появиться.

    В то время компания Intel продвигала технологию OpenMP. По крайней мере, нам так казалось. И мы решили повторить рисковый эксперимент: создать инструмент статического анализа кода для параллельных программ, построенных на технологии OpenMP. Вообще, статический анализ кода параллельных программ — задача неблагодарная и в общем случае не решаемая. Здесь царствуют динамические анализаторы кода. Хоть какой-то статический анализ параллельных программ возможен, только если код программы специальным образом размечен, чтобы подсказать анализатору, какие блоки будут выполняться параллельно, а какие нет. Здесь технология OpenMP крайне удачна для анализатора. Директивы "#pragma omp ...." и есть та самая, так необходимая разметка для анализатора.

    Мы подробно изучили тему программирования с помощью OpenMP и убедились, что есть ошибки, которые можно выявлять статическим анализом кода. Интересующиеся могут познакомиться с нашей статьёй: "32 подводных камня OpenMP при программировании на Си++".

    В целом, новая тема была выбрана неверно. Совсем неверно. Если с 64-битностью интерес был и есть, пусть и не такой большой, как хотелось, то в случае OpenMP интереса не было совсем.

    Причин для невезения, видимо, было несколько:

    1. Технология OpenMP не стала мейнстримом. Она занимает скромную позицию наравне с другими технологиями параллельного программирования.
    2. Из пункта один следует, что не так много программистов используют OpenMP в своих проектах. Следовательно, спрос в любом случае будет мал. Помимо этого, мы, видимо, не смогли выйти на эту группу разработчиков и донести до них информацию о существовании инструмента VivaMP.
    3. Статический анализ для поиска ошибок в параллельных программах всё равно слаб и сильно проигрывает другим инструментам.

    Проект VivaMP не задался. Он был просто никому не нужен. В почте практически не было вопросов об этом анализаторе или сообщений об ошибках в нём. Мир просто проигнорировал его существование

    VivaMP в дальнейшем был интегрирован в PVS-Studio, а в 2014 удалён. Стандарт OpenMP продолжал развиваться, в нем появлялись новые возможности и новые ключевые слова. Их надо было поддерживать, а смысла это делать для мертворожденного инструмента не было. Только трата сил и никакой пользы. Мы собрались с духом и удалили эту часть анализатора.

    VivaMP — первый наш большой промах. Все-таки создать и продвинуть новый инструмент — это большая работа и много потраченного времени.

    Несмотря на эту неудачу, в 2009 году мы нашли в себе смелость и силы отказаться от заказной разработки и полностью посвятить себя развитию анализаторов. Viva64 начал приносить, хоть и слабый, но достаточный для автономного существования доход. В это время наша прибыль составляла намного меньше, чем мы могли бы получать, просто устроившись куда-то программистами.

    PVS-Studio с анализатором общего назначения, первые успехи


    В 2009 году мы объединили Viva64 и VivaMP в единый продукт в надежде что диагностики VivaMP будут покупать как довесок к 64-битным диагностикам. Результата это никакого не дало, так что подробнее рассказывать про это смысла нет.

    Тем не менее, стоит отметить 2009 год, как важную веху в жизни нашей компании. Именно в этом году появился анализатор PVS-Studio, который вначале представлял собой как раз объединение Viva64 и VivaMP.

    Кстати, заодно, давайте поговорим о названиях. Анализатор Viva64 появился как желание выразить мысль: «Да здравствует 64-битный мир!». А именно само слово «viva» было навеяно недавним прослушиванием мною песни «Viva Forever». Я предложил использовать именно такое название Евгению, и он согласился. Аналогичным образом был назван и наш сайт www.viva64.com, который мы никогда не видели смысла переименовывать, так как его название постепенно стало популярным.

    Название PVS-Studio образовано более сложным образом. Первые три буквы — это сокращение от названия нашей компании OOO «Program Verification Systems». «Studio» было добавлено, чтобы подчеркнуть, что это не просто один инструмент, а коллекция инструментов, собранных вместе. На самом деле, название не очень удачно, так как его очень часто пишут неправильно: кто-то не ставит черточку, кто-то вместо PVS пишет PSV и так далее. Если бы мы выбирали название сейчас, мы использовали бы что-то более простое. Собственно, так мы и поступили, создавая CppCat, но это совсем другая история, о которой я поговорю ниже.

    Вернёмся к основной линии повествования. В 2010 году мы решили, что сможем усилить интерес к анализатору PVS-Studio, добавив к нему немного диагностик общего назначения. Причем эти диагностики мы планировали сделать бесплатными, так как не верили, что на них можно что-то заработать. В сфере диагностик общего назначения для C и C++ в то время царствовали такие инструменты, как Coverity, Parasoft C/C++test, Klocwork, Gimpel PC-Lint и так далее. Мы не видели никакого смысла даже пытаться потеснить эти инструменты. Поэтому бесплатные диагностики общего назначения мы планировали сделать исключительно в рекламных целях. Идея была такая: человек проверяет бесплатно свой проект, а заодно узнает о платных диагностиках, связанных с 64-битностью и OpenMP.

    В ноябре 2010 мы выпустили первую бета-версию PVS-Studio 4.00, в которой появился новый набор правил статического анализа общего назначения. На тот момент их было 45 штук. Вот статья про это событие: "Трепещи, мир! Мы выпустили PVS-Studio 4.00 с анализатором общего назначения".

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

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

    Мы услышали этот сигнал из космоса и быстро пересмотрели свои подходы. Поэтому вышедшая через месяц релизная версия PVS-Studio 4.00 была уже платной. Пришлось даже написать объяснительную статью, почему мы так быстро передумали: "Почему PVS-Studio 4.00 будет платным решением". Статью можете не читать, так как я скажу, что её смысл сводится к «мы хотим денег».

    Итак, PVS-Studio стал представлять собой комплект из трех анализаторов (Viva64, VivaMP, диагностики общего назначения), которые мы начали продавать как единое целое. В этой же версии впервые появились корпоративные лицензии (Site License).

    Шло время, анализатор PVS-Studio развивался и постепенно начинал приносить больше денег. В PVS-Studio 4.30 появляется инкрементальный анализ — возможность автоматически запускать анализатор для тех файлов, которые только что были изменены и перекомпилированы. Это позволило начать регулярно использовать PVS-Studio на локальных машинах разработчиков.

    А еще в PVS-Studio 4.32, которая вышла в июле 2011 года, мы отказались от лицензий для одного пользователя. Это было ещё одно из самых лучших бизнес-решений в истории компании. Мы поняли, что PVS-Studio — это командный инструмент, который приносит пользу всему проекту, независимо от того, сколько именно человек непосредственно с ним работают.

    В начале 2012 года вышел PVS-Studio 4.53, в котором уже насчитывалось 100 сообщений анализа общего назначения (V501-V600). Вскоре также появился набор диагностик «Микро-оптимизации» для поиска тех мест падения производительности, которые можно обнаружить статическим анализом.

    Так прошли 3 года, когда мы принимали верные и полезные решения по развитию проекта. Это слишком долго, пора было делать глупости.

    Embarcadero RAD Studio, вторая ошибка


    История будет короткой, так как особенно и рассказывать не о чем. В PVS-Studio 5.00 появилась интеграция в Embarcadero RAD Studio. Нам казалось, что в мире полно пользователей C++Builder. Мы были неправы. Ну или мы просто их не нашли.

    В целом, история была аналогична VivaMP. Да, где-то он в мире RAD Studio используется, но уже очень мало. Никакого интереса программистское сообщество к событию не проявило. Как и с VivaMP, не было ни писем с вопросами, ни сообщений об ошибках. Просто тишина.

    Естественно, было потеряно время и силы на поддержку Embarcadero RAD Studio и рекламу новых возможностей.

    Впрочем, безумия с Embarcadero RAD Studio нам показалось мало, и мы без отдыха, через год, совершили новую серьезную ошибку.

    CppCat, третья ошибка


    Мы выпустили продукт CppCat 1.00 — основанный на PVS-Studio недорогой статический анализатор. Мы его называли «альтернативой PVS-Studio за $250». Идея была в том, чтобы выпустить статический анализатор высокого уровня, но за очень небольшие деньги. Он был сильно дешевле. Якобы тогда намного больше разработчиков будут покупать и использовать наши решения. Возможно, мы бы даже тогда совсем отказались от PVS-Studio, который представлялся нам большой и тяжелой программой с историей, в противовес легкому и молодому CppCat, в котором простой интерфейс сочетался с мощным анализом кода.

    Думаю, по названию главы вы уже догадались, что это была плохая идея. Я решил не описывать здесь подробности этой ошибки, так как они будут фактически пересказом статьи "Мы закрываем проект CppCat". Крайне рекомендую эту статью к прочтению, она небольшая и весьма интересная.

    Рисунок 6. Проект CppCat был хорош всем. У него было простое название, в нем были простые настройки, его мог приобрести себе индивидуальный разработчик. Плохо было одно: он не приносил денег.


    Рисунок 6. Проект CppCat был хорош всем. У него было простое название, в нем были простые настройки, его мог приобрести себе индивидуальный разработчик. Плохо было одно: он не приносил денег.

    Чуть более чем через год мы закрыли проект CppCat, вновь потратив время и силы впустую. Как видите, мы наделали массу серьёзных ошибок, каждая из которых могла нас разорить. Зато теперь мы стали намного аккуратней и подходим к новым экспериментам более вдумчиво, заранее закладывая ресурсы на случай очередного промаха.

    Кстати, чуть ранее закрытия CppCat, мы заодно удалили поддержку Embarcadero RAD Studio и диагностик OpenMP. Мы поняли, что пора избавляться от балласта, который не приносит денег, но всё равно требует усилий на поддержку.

    Наши дни


    Неудачи с CppCat, VivaMP, Embarcadero RAD Studio не подорвали наш энтузиазм, и мы вложились в три новых направления:

    1. Анализ C# кода;
    2. Поддержка Linux;
    3. Бесплатный вариант лицензии PVS-Studio.

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

    Можно отсчитывать время полноценного начала существования нашей компании с 2009 года, когда мы перешли на самоокупаемость без поддержки аутсорсинговых проектов. На тот момент нас было 4 человека. По прошествии 7 лет наша команда PVS-Studio состоит из 24 человек. Конечно, это нельзя называть большим успехом, но как получилось, так и получилось. Я не вижу смысла приукрашивать действительность. Несмотря на 10 лет пути, мы считаем, что находимся только в начале и только учимся по-настоящему делать и продавать наш программный продукт.

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

    Рисунок 7. Не сдавайтесь!


    Рисунок 7. Не сдавайтесь!

    Ах да, баги Viva64 v1.0


    Я был бы не я, если бы не проверил первую версию анализатора Viva64 с помощью современной версии PVS-Studio. Ошибок нашлось совсем мало в силу крошечного размера ядра анализатора того времени. Нашего кода, так там, вообще, всего 3-4 тысячи строк. На тот момент ядро анализатора Viva64 состояло всего из 210 файлов и насчитывало 37 KLOC. Для сравнения, сейчас ядро PVS-Studio для анализа C/C++ кода состоит из 320 файлов и насчитывает уже 208 KLOC. Соответственно, количество кода, написанного нами, увеличилось где-то в 40 раз.

    Примечание. Ещё раз уточню, что речь идёт именно о ядре для анализа C и C++ кода. Помимо этого, существует Plugin для Visual Studio, ядро анализатора для C#, утилита Standalone и так далее. Так что общий размер кода за эти годы вырос в сотни раз.

    Итак, рассмотрим предупреждения современного анализатора, которые мне показались интересными, чтобы включить их в статью.

    rw_table_sanity_check(const rw_table table[])
    {
      unsigned n = (sizeof table)/(sizeof table[0]);
            
      if (n < 2) return;
    
      for (const char* old = (table++)->name; --n; old = (table++)->name)
          if (strcmp(old, table->name) >= 0) {
              cerr << "FAILED: '" << old << "' < '"
                    << table->name << "'" << endl;
              assert(! "invalid order in presorted array");
      }
    }

    Эта ошибка выявляется сразу двумя предупреждениями PVS-Studio:

    • V511 The sizeof() operator returns size of the pointer, and not of the array, in 'sizeof table' expression. lex.cc 822
    • V514 Dividing sizeof a pointer '(sizeof table)' by another value. There is a probability of logical error presence. lex.cc 822

    Ошибка относится к подсистеме юнит-тестов. Тест, на самом деле, ничего не проверяет, так как переменной n присваивается значение 0. Ошибка в том, что table — это просто указатель, а не массив.

    А вот ошибка, которую сделал лично я:

    bool IsLiteralFFFFFFFF(const char *buf, size_t len) {
      if (len < 10)
        return false;
      
      if (buf[0] != '0' && (buf[1] != 'x' || buf[1] != 'X'))
        return false;
      ....
    }

    Предупреждение PVS-Studio: V547 Expression 'buf[1] != 'x' || buf[1] != 'X'' is always true. Probably the '&&' operator should be used here. vivacasts.cpp 632

    Не работает быстрая проверка, что литерал должен начинаться с символов «0x» или «0X». Проверка считает правильными любые строки, которые начинаются с символа '0'.

    Немного длинный код, но я решил его всё-таки не сокращать:

    Ptree* Append(Ptree* p, Ptree* q)
    {
        Ptree *result, *tail;
    
        if(p == 0)
            if(q->IsLeaf())                          // <=
                return Cons(q, 0);
            else
                return q;
    
        result = tail = Cons(p->Car(), 0);
        p = p->Cdr();
        while(p != 0){
            Ptree* cell = Cons(p->Car(), 0);
            tail->SetCdr(cell);
            tail = cell;
            p = p->Cdr();
        }
    
        if(q != 0 && q->IsLeaf())                    // <=
            tail->SetCdr(Cons(q, 0));
        else
            tail->SetCdr(q);
    
        return result;
    }

    Предупреждение PVS-Studio: V595 The 'q' pointer was utilized before it was verified against nullptr. Check lines: 360, 374. ptreeutil.cc 360

    В функции произойдёт разыменование нулевого указателя, если оба фактических аргумента окажутся равны nullptr.

    Следующий код вполне оправдан для тех времён, но сейчас так писать уже нельзя:

    Class* Environment::LookupClassMetaobject(Ptree* name)
    {
        TypeInfo tinfo;
        Bind* bind = 0;
    
        if (this == 0) {
            TheErrorLog().Report(
                MopMsg(Msg::Fatal, 
                       "Environment::LookupClassMetaobject()", 
                       "0 environment"));
            return 0;
        }
      ....
    }

    Предупреждение PVS-Studio: V704 'this == 0' expression should be avoided — this expression is always false on newer compilers, because 'this' pointer can never be NULL. environment.cc 115

    Таких проверок ещё есть с 10 штук.

    На этом всё. Наверное, мои читатели ждали большего, но, действительно, больше ничего заслуживающего внимания нет. Просто 37 KLOС — это очень мало, и мы всегда очень тщательно подходили к написанию кода и тестированию.

    Заключение


    Из интересных наблюдений я могу сказать, что 10 лет назад я представлял организацию работы фирмы сильно по другому. Мне казалось, что когда всё наладится, я и Евгений будем заниматься творческими вопросами, разрабатывать стратегии развития и вообще сидеть в креслах с умным задумчивым видом. Но выяснилось, что чем дальше, тем больше наша работа напоминает работу пожарных, которые самоотверженно должны сражаться с различными бедами. А чем большее количество площади в офисе мы занимаем, и чем больше сотрудников, тем больше становится этих «пожаров» и тем более они разнообразны по своей природе. Примеры: проблемы с электричеством, протечки потолка, заклинивший замок в двери, ликвидация нарушения в виде недоплаченного налога в размере 1 копейки, и так далее. Это, конечно, не значит, что лично я или Евгений полезем самостоятельно менять кондиционер, пробитый этой зимой сосулькой. Однако, организовать его починку нужно будет именно нам.

    Рисунок 8. Свежая зимняя проблема. Вот так выглядят трудности стартапов. Они вовсе не в том, что выбран не тот Framework.


    Рисунок 8. Свежая зимняя проблема. Вот так выглядят трудности стартапов. Они вовсе не в том, что выбран не тот Framework.

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

    Рисунок 9. Я и Сергей Хренов за изготовлением правильного Press Wall. Хочешь сделать что-то хорошо, сделай это сам.


    Рисунок 9. Я и Сергей Хренов за изготовлением правильного Press Wall. Хочешь сделать что-то хорошо, сделай это сам.

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

    Спасибо всем за внимание. На этом я заканчиваю и поздравляю всех с наступающим Новым годом.


    Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. PVS-Studio project — 10 years of failures and successes.
    Метки:
    PVS-Studio 171,28
    Ищем ошибки в C, C++ и C# на Windows и Linux
    Поделиться публикацией
    Похожие публикации
    Комментарии 83
    • +2
      Кстати первая наша статья про разработку 64-битных приложений была опубликована в ноябре 2006 года. Однако время летит…

      Радует, что она до сих пор открывается на сайте :-).
      • +12
        Прочитал на одном дыхании! Успехов вам;-)
        • +7
          Успехов, Андрей! С наступающим! )
          • +1
            Спасибо! С наступающим!
          • +5
            Хорошая история и хорошо написано. Успехов вам.
            • +3
              Отличная история! Успехов в наступающем году!
              • 0
                Успехов! Автономный анализатор, позволяющий проверить, например, встраиваемые проекты, тоже не оправдал ожиданий? Не возникало мыслей привезти анализатор на Embedded World? Все конкуренты там постоянно «светятся».
                • +1
                  Прошу пояснить, что значит автономный? Если речь идёт про утилиту Standalone, то она никуда не делась.

                  Embedded область нам пока не понятна, но будем пробовать работать и с ней постепенно.
                  • +1
                    Embeded не так уж сильно отличается от мэйнстрима. Команды небольшие, понятие качества программы заменяется качеством продукта. Не так важно, если программа вылетает раз в час. Важно, что она перезапускается так, что пользователей этих слетов не заметит. И наоборот, если программа вылетает раз в месяц, но при этом не перезапускается автоматически — это ужасно.

                    То есть embeded — это активная защита от ошибок (надежная работа независимо от ошибок в программах). Тогда как статанализ — это пассивная защита.

                    я давно уже планирую серию статей про «ненастоящих программистов», чтобы рассказать, что у нас и как. Надеюсь, на зимних каникулах надеюсь, что пару опубликую.
                    • 0
                      Здорово, очень хотелось бы почитать. Авось что-то новое о нас узнаю :)
                      • 0
                        ну в общем это ближе всего к DIY, но за деньги. :-)
                        • 0
                          Великолепно. Жду поста как приглашение к занятной дискуссии :)
                • +1
                  Не наша тема, не сильны мы в embedded.
                • +3
                  А маскот когда появился?
                  • 0
                    Что такое «маскот»?
                    • +3
                      Единорог ваш
                      • +2
                        4 апреля 2011. По крайней мере в этот день картинка попала в систему контроля версий.
                      • +1
                        Маскот — персонаж, то бишь единорог наш.
                    • 0
                      Спасибо, познавательная статья. Я пробовал ваш анализатор, впечатляет, но параллельно использовал cppcheck, его особенностью, лично для меня, является помощь в оформлении кода, например он подсказывает, что нужно в объявление конструктора добавить ключевого слово explicit или, что переменную можно создать внутри цикла, а не снаружи и прочие подобные плюшки, которые помогают писать чистый код и использовать ключевые слова там где они нужны. С увеличением опыта программирования на С++ выработались специальные приёмы программирования, которые помогают избегать банальных ошибок. Так исторически сложилось, что в качестве редактора кода я использую eclipse, уж очень сильно к нему прирос, а в нём имеется интеграция с cppcheck, git, doxygen и много чего другого, что я активно использую. Я не призываю разработчиков PVS-Studio тратить силы и время на написание плагина под eclipse и прочие IDE, так как нет в планах покупать анализатор PVS-Studio, во всяком случае на данный момент. Но возможно будет полезным внедрить возможность помогать программисту писать красивый код, к примеру мой многолетний опыт показал, что я только сейчас стал понимать всю глубину С++, стал активно применять ключевые слова: explicit, mutable, noexcept итд. Удобно, когда все инструменты собраны в одном месте, для меня eclipse самый лучший инструмент для написания кода потому, что в нём я объединяю почти все инструменты, которыми пользуюсь. Может быть моё мнение будет интересно разработчика, а может нет, я просто поделился своими мыслями.
                    • –2
                      Удивляет ваша позиция по поводу CppCat.
                      Хотели сделать как лучше, сделать для разработчиков, но в итоге пожадничали и выставили слишком большой ценник, поэтому интереса и не было.
                      И не надо говорить, про зарплаты программистов, 250$ даже для 2014 года — порой слишком дорого.
                      Да, и посмотрите на ценники других инструментов? Тот же решарпер (на тот момент был только для C#) стоил гораздо дешевле вашего поделия.
                      За статью спасибо.
                      • +6
                        Мы вообще не жадные. Proof. Но бизнес должен приносить деньги и нет смысл тратить силы на неэффективные направления. Про то что $250 это много, я всерьез воспринимать не могу. Люди тратят много больше даже на бестолковые вещи или хобби. Это означает, что инструмент просто не нужен. А если не нужен, любая цена будет велика.
                        • 0
                          Полностью поддерживаю мнение автора, лучше делать один инструмент, но качественный, чем создавать множество инструментов, которые предназначены для одного и того же, но при этом каждый из них будет иметь свои недостатки. Язык С++ очень сложный и с появлением С++11 и С++14 стал ещё сложнее, работы для статического анализатора тоже прибавилось. Много интересных нюансов описывает Скотт Мэйерс в своих книгах по С++, было бы полезно иметь инструмент, который мог бы подсказывать где можно улучшить код, например показывать место где желательно использовать оператор переноса, некоторые функции можно определить как noexcept или наоборот, если функция определена как noexcept, а внутри используется обработка исключению, то анализатор предупредит об этом. С приходом новых стандартов в С++ требуется время на осмысление новшеств и велика вероятность наделать глупостей и тут бы анализатор мог быть хорошим помощников в освоении новых стандартов.
                          • 0
                            $250 — это 15 труб. По моим оценкам такая цена экономически выгодна, начиная с зарплаты программиста в тысяч 40 (ФОП 60 труб). Возможно, что проблема в бесплатной демо-версии. Дело в том, что основной эффект от статанализатор — идет при его первом применении. И эффект этот не только в нахождении застарелых ошибок, но и в наглядном обучении, как лучше не писать.

                            На самом деле, у многих людей есть проблема с поиском непонятных ошибок в коде. Думаю, что за $20-$30 — у вас бы не было отбоя от желающих один раз проверить проект и получить отчет (по всем анализаторам, а не только по PVS). Понятно, что вам это неинтересно, но такой стартап, ищущий ошибки в чужом коде, вполне жизнеспособен.
                            • +1
                              Сейчас есть возможность использования PVS-Studio с бесплатной лицензией, думаю этого вполне достаточно для ознакомления с продуктом и лицензии за 20$ тут не нужны. Вообще немного удивлён, что разработчики адаптировали свой продукт под Linux, где царствует бесплатное ПО, а Mac OS остаётся без внимания, ведь именно Mac OS царство комерческого ПО и не просто ПО, а довольно качественного, вероятность заработать денег на этой OS должна быть выше, чем в Linux. Конечно под Mac OS основной язык Object-C, но там там также есть Qt C++, а теперь ещё и Visual Studio с С#.
                              • +2
                                Вообще немного удивлён, что разработчики адаптировали свой продукт под Linux, где царствует бесплатное ПО, а Mac OS остаётся без внимания...

                                Как я понимаю PVS-Studio предназначен в первую очередь для проверок кода на сервере сборки, а вот что-то хоть отдалённо похожее на сервер с MacOS я последний раз видел году эдак в 2005 на студии занимающейся видео-клипами и использующих Mac для обработки видео.
                                А бесплатное ПО никак не мешает существованию таких дистрибутивов как RHEL и SLES, а именно их и предпочитает энтерпрайз, да и телеком по большей части…
                                • +1
                                  Как я понимаю PVS-Studio предназначен в первую очередь для проверок кода на сервере сборки

                                  Ну блин, они же в каждой второй статье пишут что это неправильное применение их продукта!


                                  У них же большинство возможностей заточены на интерактивную работу, а не на пакетную...

                                  • +4
                                    Неправильное применение, это разовые проверки перед релизом.

                                    Ежедневные проверки на сервере как раз нужны на случай, если кто-то из разработчиков пренебрегает инкрементальным анализом.
                                • 0
                                  Гм, вы много видели железок под windows или mac OS? ну на банкоматах винда, а где ещё? Зато почти в каждой железке — linux. В тех же роутерах, например. В мобильниках, в планшетах… Только в самых маленьких — FORTH или что-то вроде FreeRTOS.
                                  • 0
                                    Вообще немного удивлён, что разработчики адаптировали свой продукт под Linux, где царствует бесплатное ПО, а Mac OS остаётся без внимания, ведь именно Mac OS царство комерческого ПО и не просто ПО, а довольно качественного, вероятность заработать денег на этой OS должна быть выше, чем в Linux.
                                    На Linux есть много разных миров. Enterprise на серверах — это почти один Linux, а софт под него кто-то ведь разрабывает. А MacOS — это, как раз, очень-очень узкая ниша, iOS, фактически, и всё — но там своя, очень серьёзная головная боль, чтобы Objective C++ хотя бы распарсить.
                                    • 0
                                      Я хотел сказать, что под Linux очень много проектов с открытым исходным кодом, разработчики таких проектов могут сейчас использовать PVS-Studio бесплатно, соответственно не принесёт ни рубля авторам анализатора. Основной доход, на мой взгляд, будет от коммерческих проектов, а они в основном на windows или mac os. По поводу узкой ниши для mac os — не соглашусь, в нашей стране эта конечно так, но в штатах она почти в каждом доме и офисе и её там очень любят. Когда я создавал свой проект он изначально был только для windows, так как основная масса потребителей использует эту os. Потом начали поступать письма адаптировать программу под linux, благо проект создавался на Qt и проблем с портированием не возникло, но как показала статистика, на несколько тысяч пользователей только несколько человек (меньше 5) использует linux, но при этом у большого числа пользователей (около сотни) стоит дома iMac или macbook и они используют программу на mac os через виртуальную машину Parallels и не возмущаются.
                                      • +1
                                        Почти весь большой enterprize — это linux, там не только коммерческое ПО, но и очень дорогое и большое коммерческое ПО. Mac OS — одна очень узкая ниша — десктоп с маленькими пользовательскими приложениями из стора (чаще всего на ObjC).
                                  • +3
                                    Изначально приведены 250$ в ценах 2014 года., то есть 8750. Пакет мс офиса. Ну не серьезно, блин.
                                    • –1
                                      А зарплаты программеров примерно привязаны к курсу доллара. Ну или вокруг меня так случайно сложилось.
                                      • +1
                                        Вот да. Но при цене тех лет экономически выгодно было использовать, если только твои доходы от программирования не пару мрот)
                                        Кстати, не соглашусь, что основной эффект от первого применения, особенно для человека, который еще только учится писать и не все тонкости понимает — основной эффект будет как раз в постоянной дополнительной проверке. Да и на сложных проектах должно бы веселее.
                                        Только культуру использования надо прививать еще в момент обучения, а то некоторые программисты умудряются писать, забивая даже на предупреждения компиляторов…
                                        • –3
                                          Как вы считаете экономическую выгоду? Можете описать методику?

                                          некоторые программисты умудряются писать, забивая даже на предупреждения компиляторов…

                                          Ну так и на предупреждения анализатора забьют такой же болт… Впрочем, вы ещё не видели, как пишут математики… Для математика правильно все, что математически эквивалентно.
                                          • +1
                                            Как вы считаете экономическую выгоду?

                                            Так же как и вы для 15 тысяч
                                            Впрочем, вы ещё не видели, как пишут математики…

                                            я видел как пишут программисты.
                                            как вам поиск артикула по названию материала — путем цикла по 10 тысяч строк без брека, а потом следующим шагом такой же цикл, только возвращающий уже первых 5 символов того же артикула?
                                            • –4
                                              Так же как и вы для 15 тысяч

                                              То есть вы подтверждаете мою гипотезу, что PVS-studio экономит 2 недели труда разработчика по сравнению с бесплатным CppCheck? А исследования были?

                                              Индийский код — не новость. Выльем воду из чайника и сведем задачу к предыдущей.

                                              Меня больше поражают американцы. Российская техника обязана работать при любом отказе датчика, надежно диагностирует два одновременных отказа и старается диагностировать тройной отказ.

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


                                              А вместо изменения порядка проверок они всего лишь заменили пластмассовый датчик на металлический.
                                              • +3
                                                «То есть вы подтверждаете мою гипотезу»
                                                Я выдвигаю мысль, что за год работы (около 220 официальных рабочих дней) программиста инструмент в 1,10$/день окупился бы для любого нормального программиста не хуже ежедневной чашки кофе.
                                                А какая программа лучше ищет ошибки — это уже заход на холивар, результаты проверок PVS-studio можно посмотреть в куче статей на хабре, так что можете запилить своё сравнение в любой момент: взять десяток свободных проектов и последовательно прогнать по ним обе программы, благо бесплатная версия PVS — доступна.

                                                PS. Это был, так сказать, «русский код»… причем от специалиста «с дипломом».
                                                • –3
                                                  Скажите, а болгарку, дремель, микроскоп, паяльную станцию, логический анализатор, JTAG? осциллограф вы уже себе купили? А это все инструменты дешевле 1$ в день. я вообще не понимаю, как вы ловите определенные типы ошибок без осциллографа! :-) Ну вот как вы без осциллографа найдете причины CRC-error в RS-485?

                                                  А какая программа лучше ищет ошибки — это уже заход на холивар,

                                                  — Армяне — лучше, чем грузин.
                                                  — Чем лучше?
                                                  -Чем грузин!
                                                  (с) анекдот
                                                  Кто лучше ищет сферические ошибки в вакууме — это неинтересно. Интересно, найдет ли PVS-studio что-то важное, в коде, уже проверенном бесплатными анализаторами. Причем не в абстрактном коде, а в конкретном.

                                                  PS. Это был, так сказать, «русский код»… причем от специалиста «с дипломом».

                                                  Если вместо того, чтобы с 13-17 лет писать код до 23х лет сидеть за партой — то диплом, конечно, будет. А вот программер — уже не получиться.
                                                  • +3
                                                    Скажите, а болгарку, дремель, микроскоп, паяльную станцию, логический анализатор, JTAG? осциллограф вы уже себе купили? А это все инструменты дешевле 1$ в день

                                                    Когда я делал полный ремонт своей комнаты своими руками я купил себе перфоратор вместо имевшейся ударной дрели. И болгарка у меня тоже есть с тех времен на всякий случай. С учетом количества раз использования перфоратора на той же даче, при замешивании раствора и прочем — он уже давно окупился. А вот болгарка — нет, так как задач под нее до сих пор не нашлось (планировался перенос дверей, но так и не сделали). По этой же причине у меня нет дремеля, который я легко куплю по первой же необходимости работать именно им.
                                                    И вот когда клал ламинат, то купил самый дешевый лобзик, который окупился уже даже этим (ибо нанять человека на укладку ламината стоило сильно дороже) и который я потом так же гонял в хвост и гриву на даче. И да, например, если бы я постоянно собирал мебель или крутил саморезы, у меня был бы хороший шуруповерт, но пока для моих задач, в том числе на даче, мне всегда хватало отвертки и перфоратора с переходником на биты (вообще, перфоратор, это такая универсальная вещь!)

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

                                                    С учетом, что прочий перечисленный инструмент я не использую от слова совсем, так как отрасль моей деятельности — другая, то да, у меня нет микроскопа, осцилографа и пр.

                                                    Так что вообще-то это нормально иметь свои инструменты, занимаясь чем-либо. Более того, занимаясь той же мебелью, нормально иметь свои профессиональные и дорогущие инструменты, типа шурика или лобзика на порядок дороже дешевого шлака. Именно не в пару раз.

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

                                                    А мы тут обсуждаем использование проф.программы для программиста C++, который этим как бы зарабатывает себе на жизнь и который в идеале должен бы стремиться сделать свой код более стабильным и менее багнутым, но при этом не усложнить свою жизнь сверхмеры.

                                                    Интересно, найдет ли PVS-studio что-то важное, в коде, уже проверенном бесплатными анализаторами.


                                                    Нееет, естественно не найдет. Ведь все прочие разработчики, того же хрома, никогда в жизни не додумаются использовать статанализаторы кода, ага. Они ж тупые (читать голосом Задорнова).
                                                    Может внимательнее почитаете статьи, которые на хабре выкладываются? В нескольких из них я точно встречал упоминания, что код явно проверяется другими инструментами.
                                                    Кто лучше ищет сферические ошибки в вакууме — это неинтересно.

                                                    Если же вы считаете, что параллельная прогонка на нескольких проектах — это сферические поиск в вакууме, то мне даже не понятно, что вы хотите получить вообще? Просто поспорить?

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

                                                    Если вместо того, чтобы с 13-17 лет писать код до 23х лет сидеть за партой — то диплом, конечно, будет. А вот программер — уже не получиться.

                                                    Ох, уж эти сказочки! Ох, уж эти сказочники. (с)
                                                    Вот, кстати, в тут до этого спрашивали пруфы на исследования. Что ж, я возвращаю вам долг: а пруфы на исследования, подтверждающие ваше высказывания будут?
                                                    • –3
                                                      Так что ваши аналогии — лживы по той простой причине, что вы перечислили кучу инструмента, который далеко не всем нужен для жизни, работы и или хобби.

                                                      Дивитесь! я перечислил инструмент, используемый в нашей фирме именно при отладке программ. И не только в нашей — можете перепроверить у других embedчиков.

                                                      Болгарка и дремель используется на финальных стадиях отладки, когда нужно монтировать оборудование на трактор или тепловоз. Не все можно отладить в офисе или на автомобиле.

                                                      Паяльная станция — при отладке используется регулярно. Последний раз — дня 3 назад. Потребовалось мне часто делать RESET процессору — припаяли кнопочку.

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

                                                      Логический анализатор — незаменимый инструмент при отладке протоколов. Особенно — при общении с хитрыми микросхемами. Возьмите datasheet на любую микросхему — там обязательно будет временная диаграмма сигналов. И если микросхема не отвечает — первым делом снимается эта самая временная диаграмма.

                                                      JTAG вообще незаменим ничем. Как вы без него зальете прошивку на ПЛИС или некоторые модули микропроцессоров? Да и самый низкоуровневый код им отлаживается.

                                                      Осциллограф незаменим при отладке ошибок типа CRC error. Первое. что нужно сделать — это посмотреть форму сигналов. Могут быть заваленные фронты или звон…

                                                      Вольтметр (лучше универсальный авометр) тоже незаменим при отладке. Ибо если не работает ничего — вначале смотрится, есть ли питание на процессоре и портах. а потом — осциллографом смотрится тактирование.

                                                      А мы тут обсуждаем использование проф.программы для программиста C++, который этим как бы зарабатывает себе на жизнь

                                                      Ну вот я привел вам список наших профессиональных инструментов. Удивляет?

                                                      Меня тоже удивляет ваше понятие «программист С++». Потому что мы просто программисты и пишем на чем угодно. на Delphi, Си, shell, javscript, PHP, языках IEC 61131-3, языках ПЛИС., куче разных ассемблеров… по мне так, если человек умеет писать только на С++ — это не программер, а кодер. Потому что программеру почти все равно, на каком языке писать. Почти — потому что при переходе от процедурных языков к иным (FORTH, Ladder, LISP, APL...) приходится напрягать мозги.

                                                      Нееет, естественно не найдет.

                                                      Да нет, найти-то найдет, но важное ли? Ну знаю я, что если задать имя файла длиннее 4096 символов, программе станет очень плохо. Вот только, чтобы его задать — надо открыть корпус, спаять диагностические кабели и подключить их. а если уж подключили — так можно и свою собственную прошивку залить, чего мелочиться со взломом нашей?

                                                      Может внимательнее почитаете статьи, которые на хабре выкладываются?

                                                      Почитал. Ни одного embeded-проекта не проверено. и даже авторы PVS-studio сомневаются в его применимости в embeded.

                                                      Если же вы считаете, что параллельная прогонка на нескольких проектах — это сферические поиск в вакууме, то мне даже не понятно, что вы хотите получить вообще?

                                                      Хочу понять пользу для своих проектов. У каждого — свои стили написания и свои типичные ошибки в коде. Да и цена PVS-studio для мелкой фирмы очень велика. Так что оправдывает ли польза цену — вопрос открытый.

                                                      а пруфы на исследования, подтверждающие ваше высказывания будут?

                                                      Смотря про какие высказывания речь.

                                                      Вот фото с отладки на путеправильной машине.
                                                      image
                                                      image

                                                      Зачем там болгарка и дремель — думаю, что понятно. Да и осциллограф полезен — зависало там при переходе от аккумуляторов к дизелю, надо смотреть, что с напряжением твориться.

                                                      Вы напишите, какие высказывания надо подтверждать пруфами, я отвечу, есть у меня пруфы или нет…
                                                      • +4
                                                        Дивитесь! я перечислил инструмент, используемый в нашей фирме именно при отладке программ. И не только в нашей — можете перепроверить у других embedчиков.

                                                        Ага, но спросили почему-то именно у меня, купил ли я их уже себе. Не говоря ни слова про embeded, и не уточняя связан ли я как с ним. Более того, я же нигде вроде как не утверждал, что любой разработчик ОБЯЗАН был купить данную программу. Я просто последовательно придерживаюсь мнения, что в те времена 9к рублей не были даже близко какой-то серьезной суммой для тех, кто зарабатывает на C++.

                                                        При этом вы таки купили эти инструменты, поэтому я еще более не понимаю ваше ерничение. Ведь даже тогда данный набор инструментов стоил дороже 250$. Или данный набор инструментов помогает вам писать и отлаживать программы постоянно и на всех языках? (по-моему, в этом случае нагретый паяльник приложенный к нужному месту сработает намного лучше) Или каждый из них экономит вам две недели рабочего времени?
                                                        но важное ли?

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

                                                        И шнец, и жнец, и на дуде игрец. А в реальности я не видел еще ни одного человека, который мог бы «писать на чем угодно» (слушайте, а как оно, писать на брейнфаке в эмбедед?). Обычно, достаточно ограниченный набор за хотя бы тот же год.

                                                        Да и цена PVS-studio для мелкой фирмы очень велика.

                                                        Так разговор во всей этой ветке был не о PVS. А о том, почему же не выстрелил CppCat — это разные суммы и разные программы.

                                                        А уж ваша мысль про стартап с анализами за 20-30$ — так тем более еще более утопичен. Разовые проверки никак глобально не улучшат качество написания кода в долгосрочных проектах (по хорошему, после исправления ошибок надо будет делать еще одну проверку и т.д.), а при этом есть еще и демо-версия. При этом, если у человека нет навыков и умений работы с таким анализом, то проверка пройдет, считай, в пустую.
                                                        Вы напишите, какие высказывания надо подтверждать пруфами, я отвечу, есть у меня пруфы или нет…


                                                        Прям чуть повыше моего вопроса, прям на пару строчек, была дословная цитата ваших слов в тегах quote
                                                        • –5
                                                          Более того, я же нигде вроде как не утверждал, что любой разработчик ОБЯЗАН был купить данную программу

                                                          Угу. Меня интересует, есть ли польза именно для нашей компании. С учетом текущей цены на PVS-studiobb и того, что покупается всего лишь годовая подписка.

                                                          Или данный набор инструментов помогает вам писать и отлаживать программы постоянно и на всех языках?

                                                          Угу. Осциллограф и паяльник — совсем языконезависимы. Кстати. PHP и javascript — это тоже embeded, web-интерфейс для управления береговой радиостанцией Сидит себе внутри железки C++ и PHP, а в браузере работает JS, HTML и CSS, загруженные с той же железки.

                                                          Например, наши постоянно удивляются, какого фига мы ставим важность «авария», если после их обновления всего лишь отвалилась подсистема печати и у нас начинаются проблемы с выдачей анализов пациентам.

                                                          Так у вас программы или программно-аппаратные комплексы? Если комплексы — то осциллограф и паяльник нужен. Потому что за железо и связь железок друг с другом отвечаете тоже вы. Зато и железки подбираете такие, чтобы подсистема печати была сдублирована и не отваливалась. Ну, скажем, USB на одной машине, Wifi на второй, проводной ethernet на третьей. тогда сбой подсистемы печати на двух машинах из трех уже не страшен.

                                                          А о том, почему же не выстрелил CppCat — это разные суммы и разные программы

                                                          А скорее всего у него нету серьезных преимуществ перед бесплатным cppcheck.

                                                          Разовые проверки никак глобально не улучшат качество написания кода

                                                          Написания — не улучшат. Они просто помогут найти ошибки в самом коде. Довольно много программеров не умеет искать баги. И не понимает, как их найти.

                                                          См. пример авторов PVS-studio. Товарищи не поняли, что чтобы поймать проблемы с 64битными поинтерами, надо было просто откомпилироваться на 16бит. И большая часть проблем — просто вылезла бы явно.

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

                                                          Вы на это пруф хотите?
                                                          Если вместо того, чтобы с 13-17 лет писать код до 23х лет сидеть за партой — то диплом, конечно, будет. А вот программер — уже не получиться.

                                                          Доказательств нету. Есть примеры людей из обоих категорий. ну вот пример знакомого, программирующего за деньги с 13-14 лет. В 17 он был моим сотрудником. Хотя по хорошему — лучше было бы ему быть начальником, а мне его подчиненным. Ну это просто пруф, что такие бывают.
                                                          • –3
                                                            И шнец, и жнец, и на дуде игрец. А в реальности я не видел еще ни одного человека, который мог бы «писать на чем угодно» (слушайте, а как оно, писать на брейнфаке в эмбедед?). Обычно, достаточно ограниченный набор за хотя бы тот же год.

                                                            На брейнфаке писать не приходилось. А вообще это примерно так же, как примеры на сложение и умножение. Не важно какой язык — если умножать умеете, но и на суахили умножите.

                                                            Из экзотики — ошибки можно исправлять и на неизвестном языке. 30 лет назад я сначала целый вечер правил деткам ошибки в их программах и только после отбоя сел читать описание языка фокал.

                                                            А за год — да, набор обычно ограниченный. Но 6-7 языков в одном проекте — да, бывает.
                                    • 0
                                      А вы не прикидывали, пойдёт ли вариант распространения продукта на подписках?
                                      Как-то для pet-проектов 250$ — это дороговато.
                                    • +4
                                      «250$ даже для 2014 года — порой слишком дорого.»
                                      250*35 = 8750.
                                      Серьезно? Может тогда человеку стоило еще тогда сменить отрасль и уж тем более НЕ ПИСАТЬ на C++?

                                      Например, в мебели в то же время за эти деньги можно было купить один раскрой, или одну программу составления сметы, или треть от программы моделирования корпусной мебели. Ну или оплатить годовую подписку за комплект необходимых программ. И да, средние зарплаты конструкторов мебели ниже программистов, тем более на плюсах.

                                      «вашего поделия»
                                      Ваша непредвзятость заметна невооруженным взглядом. [/sarcazm_off]
                                      Хотя, с учетом, что вы приходите погадитьоставлять подобные комментарии практически исключительно только под статьи в блоге PVS-Studio, трудно удивляться.
                                      У вас давно уже сложилось мнение и вы используете любую причину дое… ся.
                                    • +1
                                      Ребят, давайте уже скинемся одной компании на 64 битный анализатор. А то слезы наворачиваются, когда видишь такую картину уже почти в 2017…
                                      Картинка
                                      image

                                      • +1
                                        Что хотите сказать этой картинкой?
                                        • +3
                                          кажись, что VS2015 32 битная
                                          • 0

                                            И Preview 17 тоже.

                                        • 0

                                          Что к чему...

                                          • НЛО прилетело и опубликовало эту надпись здесь
                                            • 0
                                              А что такого ужасного в этой картинке? У вас в исходниках много гигабайтных исходных файлов? Время компиляции не напрягает, нет?

                                              64-бита — это, зачастую, никому не нужная роскошь. Огромное количество утилит и в XXII веке, подозреваю, будут оставаться 32-битными.

                                              Конечно там, где это этого есть выигрыш 64-бита нужно использовать. Но всех туда загонять просто потому что вы это можете… зачем?

                                              P.S. Вот 16-бит отошли в прошлое легко и не напрягаясь. Потому что набрать ручками текст > 64К — никогда не было проблемой. И ещё в 80е годы на 16-битных компьютерах на это натыкались сплошь и рядом. А вот 32-бита… нет, тут ситуация иная. Собственно потому компьютеры и начинались со всяких 32-битных и 36-битных систем, 8-битные и 16-битные появились позже, как попытка упихать что-то работающее в небольшое число транзисторов.
                                              • 0

                                                А почему тогда 95 процентов софта на маке и линуксе 64битные? Кажется мне это исключительного проблема винды

                                                • 0
                                                  Можно ссылочку на статистику плиз
                                                  • 0

                                                    Все бинари в макоси, собранные для последних версий, начиная года с 2011 исключительно x86_64 или universal, который умеет обе архитектуры. Все дистрибутивы линукса со всем софтом полностью собраны для amd64, все новое проприетарное по тоже поставляется в amd64 архитектуре, даже скайп теперь amd64 only. Но точную статистику по макоси не скажу как и по линуксу.
                                                    i386 сейчас в основном используется для запуска wine.

                                                  • +2
                                                    А почему тогда 95 процентов софта на маке и линуксе 64битные?
                                                    Потому что в MacOS и Linux плохо с поддержкой 32-битных программ на 64-битных системах.

                                                    Кажется мне это исключительного проблема винды
                                                    Во-первых не проблема, а достоинство, а во-вторых — с Android такая же точно ситуация.

                                                    Собственно популярность винды во многом и обусловлена тем, что там разработчиков «калёным железом в рай» не загоняют…
                                                  • +3

                                                    Решарперу, в частности, очень не хватает памяти. И гигабайты занимают не исходники, а AST иже с ними.

                                                    • +1
                                                      Спросите у ребят из JetBrains, например, как R# весело жилось в одном процессе с 32 битной VS. Вообще, эта проблема стоит остро у любой команды, которая пишет плагин. 3Gb адресного пространства доступно всего. Как правило 2 отъедает хост. Итого, на плагин остаётся всего лишь 1-1.5 Gb. Нам тоже пришлось поплясать с бубном при написании плагина к 32 битному ArcMap'y. Какого х, имея железо с 32Гб оперативной памяти, я вообще должен париться об этом?
                                                      А что такого ужасного в этой картинке?
                                                      А то, что MS — это компания, на которую, по идее, должны все равняться в Windows мире, а она уже как 10 лет не может выродить IDE, адекватное современным реалиям.
                                                  • +1
                                                    Да уж, сосулька…
                                                    Настоящая сосулина, разбившая, наверно, кондиционер до неремонтопригодности.
                                                    • +2
                                                      разбившая, наверно, кондиционер до неремонтопригодности.


                                                      Так и есть :-(.
                                                      • +1

                                                        Сейчас делают навесы над кондиционерами, как раз для предотвращения подобного. Стоят пару тысяч, и позволяют избежать подобного.

                                                      • 0

                                                        Зато, может быть, этот кондиционер кому-то жизнь спас.

                                                      • +5
                                                        А вы отправили авторам Viva64 сообщение о найденных ошибках? :)
                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                          • 0
                                                            В нашей компании, к сожалению, используется C++ Builder. (сожаление не потому, что билдер, а потому что PVS его не поддерживает).

                                                            Проверка проектов C++ Builder всё ещё возможна с помощью утилиты PVS-Studio Standalone. Можете попробовать проверить свой проект. Правда мы сейчас не тестируем этот режим работы, так как опять-таки нет никакого интереса со стороны сообщества разработчиков.

                                                            А не может анализатор существовать отдельно от среды разработки? Типа как отдельное приложение в которое накидал файлов *.cpp и пусть оно их жуёт. Пусть хоть и с некоторым ухудшением качества анализа.

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


                                                              Раньше проверял им проект из Qt Creator. Нашел два способа уронить PVS-Studio Standalone. К сожалению, сходу не вспомню. Что-то вроде начать анализ, нажать стоп и снова начать.
                                                              • +1
                                                                А разработчики cppchek то и не знают, что фигню делают…
                                                            • 0
                                                              (del)
                                                              • +1
                                                                Супер статья! Спасибо вам за статью и успехов вам!
                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                  • 0
                                                                    Помню ваши статьи про ошибки в 64-битных приложениях ещё на Intel Software Network. Спасибо за статью и успехов в новых направлениях! Даже если вы и повторяете в какой-то мере функционал R#, как пишут многие на Хабре, здоровая конкуренция не бывает вредной.
                                                                    • +1

                                                                      Молодцы! Очередное подтверждение, что чтобы добиться успеха, надо вкалывать :-)


                                                                      На программе «Старт» мои знакомые тоже сидели много лет назад. Там были странные условия на фонд оплаты труда, можно было платить одному человеку не больше смешной суммы. Они нанимали фиктивных знакомых, которые числились в конторе, но ничего не делали и их зарплату руководство вытаскивало наличными, после чего уже можно было тратить на то что надо (пусть и за вычетом налогов).

                                                                      • +1
                                                                        В старте из средств программы можно покрыть не более указанной части зарплаты. Остальную часть можно из своих платить. Но по какой-то причине про это почти никто не знает и часто это превращается в то, о чем вы написали.
                                                                      • +1

                                                                        А я помню статьи про появление VivaMP и его закрытие. Хотя к плюсам никакого отношения не имею. Просто читаю вас.

                                                                        • +1
                                                                          Там исходники первого Postal открыли — вот вам для следующей проверки =)
                                                                          • 0
                                                                            А вот и подоспела статья, о внутреннем мире анализатора: "Как PVS-Studio ищет ошибки: методики и технологии".
                                                                            • +2
                                                                              И ещё сделал обзорную презентацию о том, что представляет PVS-Studio на начало 2017 года. Можно быстро узнать, какие возможности предоставляет анализатор.
                                                                            • 0
                                                                              Решил послать весточку интересующимся анализатором PVS-Studio. Сегодня 06.03.2013 в 15.00 состоится пробный стрим, где можно будет вживую посмотреть на процесс работы PVS-Studio и интерактивно пообщаться. Присоединяйтесь к нашему стриму. Подробности (см. раздел Важно).
                                                                              • 0
                                                                                Упс. 06.03.2017. Опечаточка. :)

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

                                                                                Самое читаемое