Я по роду своей деятельности много и часто медитирую над разнообразнейшим C++ кодом. И, как говорится, у меня накопилось. Не могу больше нести это в себе. Извините, сейчас и с вами поделюсь.

Я все-таки решил разобраться, есть ли смысл при работе с итераторами писать ++iterator, а не iterator++. Мой интерес к этому вопросу возник не из любви к искусству, а из практических соображений. Мы давно хотим развивать PVS-Studio не только в направлении поиска ошибок, но и в сторону выдачи подсказок по оптимизации кода. Выдача сообщения, что лучше писать ++iterator вполне уместна в плане оптимизации.

Но вот насколько эта рекомендация актуальна в наше время? В стародавние времена, например, советовали не повторять вычисления. Считалось хорошим тоном вместо:

X = A + 10 + B;
Y = A + 10 + C;

написать так:

TMP = A + 10;
X = TMP + B;
Y = TMP + C;

Картинка такая выбрана неспроста. Опасный пост. На Хабре много тех, кто занимается и живет SEO. Собственно, я даже не против SEO. Это полезное и нужное направление. Как без него быстро вывести новый сайт в какие-то позиции вообще не понятно. Только вот беда в том, что в погоне за количеством ссылок и уникальностью контента, как-то теряется сам смысл понятия «продвижения сайта заказчика».

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

Это моя очередная заметка о том, как PVS-Studio делает программы более надёжными. То есть где, и какие ошибки он обнаруживает. На этот раз под молоток попали примеры, демонстрирующие работу с библиотекой IPP 7.0 (Intel Performance Primitives Library). Хотел, вначале, этот пост поместить в блог Intel, но потом решил, что это будет совсем уже...

Я занимаюсь созданием анализатора PVS-Studio, выявляющего ошибки в исходном коде приложений на языке C/C++/C++0x. В связи с этим мне приходится просматривать большой объем исходного кода различных приложений, где с помощью PVS-Studio были обнаружены подозрительные участки кода. У меня накопилось достаточно примеров, в которых хорошо видно, когда ошибка появилась на свет из-за копирования участка кода и его модификации. Конечно, это не новая идея, что использовать Copy-Paste при программировании плохо. Однако попробуем не отделываться рекомендацией «не копируйте код» и подойдем к этой теме более внимательно.

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

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

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

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

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

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

Предлагаем вниманию программистов новый инструмент для поиска ошибок в исходном коде приложений на языке Си/Си++. В рамках анализатора PVS-Studio реализован новый набор правил общего назначения. Эта функциональность на данный момент является бесплатной. Вы можете скачать PVS-Studio по адресу http://www.viva64.com/ru/pvs-studio-download/.

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

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

Продолжу экскурсию по ошибкам в программах и демонстрацию полезности статического анализа кода.

Это мой последний пост про пока недоступную для скачиванию версию PVS-Studio. Планирую, что через неделю вы уже сможете попробовать первую beta-версию с новым набором правил общего назначения.

Рассмотрим два проекта. Первый — Fennec Media Project. Это универсальный медиа-плеер ориентированный на воспроизведение аудио и видео в высоком разрешении. В комплект исходных кодов входит множество модулей расширения (plugins) и кодеков, но анализироваться будет только сам плеер. Исходный код последней на данный момент версии 1.2 Alpha доступен здесь.

Второй проект — qutIM. Это кроссплатформенный клиент мгновенного обмена сообщениями с открытым исходным кодом. Был проанализирован код на момент начала ноября 2010 года. Набор исходных кодов был предоставлен мне одним из разработчиков, но вы также можете скачать исходный код с официального сайта. Этот разработчик, кстати, присутствует здесь — gorthauer87.

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

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

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

Теперь попробую пояснить, про какие же ошибки мне хочется услышать и как.

У компилятора и сторонних инструментов статического анализа кода есть общая задача — выявление опасных фрагментов кода. Однако существует существенная разница в том, анализ какого типа они осуществляют. Я попробую на примере компилятора Intel C++ и анализатора PVS-Studio продемонстрировать различия подходов, и пояснить, чем они вызваны.

В качестве испытуемого на этот раз выступит проект Notepad++ версии 5.8.2.

Сегодня я хочу посвятить пост тематике, почему инструменты анализа исходного кода полезны вне зависимости от уровня знаний и опыта программиста. А польза такого анализа будет продемонстрирована на примере инструмента, который известен всем программистам — WinMerge.

В компиляторе Visual Studio C++ имеется warning C4311 ('variable': pointer truncation from 'type' to 'type') предназначенный для выявления ошибок приведения указателя к 32-битным типам данных. В Intel C++ этому предупреждению соответствует warning #810. Пример обнаруживаемого дефекта:

void *ptr = x;
int y = (int)ptr;

В Win64 размер указателя стал 64-битным, а размер int остался по-прежнему 32 бита. Явное приведение типа обрежет значение указателя, что приведет к ошибке, если указатель ссылается на объект находящимся за пределами младших 4 Гбайт памяти (0x00000000FFFFFFFF).

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

Решил написать еще один небольшой пост в продолжение темы обзора сайта Intel Software Network (ISN). Хочется рассказать о некоторых статьях, которые можно найти на сайте ISN. Тема ориентирована на программистов или тех, кто планирует ими стать.

Русский раздел сайта Intel Software Network (ISN) незаслуженно обделен вниманием российских разработчиков программного обеспечения. И у меня возникло желание прокричать об этом информационном ресурсе и его содержимом! Столько полезной информации зря простаивает!

Решил посмотреть на новый Intel VTune Amplifier XE 2011 beta и написать статью о примере использования. Правда, в процессе написания акцент частично сместился от использования Amplifier к его тестированию. Но это тоже хорошо, надеюсь, разработчики в Intel учтут пожелания и внесут изменения в следующую версию инструмента. И вообще буду критиковать и себя, и всех. :)

Вот, наконец, добрался попробовать Си++ компилятор, входящий в состав Intel Parallel Studio XE 2011 beta. Привожу краткий отчет о своих экспериментах.

Господа, хватит уже рассматривать ссылки исключительно в контексте их количества, купли/продажи и считать PR сайта, где они расположены. Пора заботиться не о роботах, а о людях. Работать с интернетом становится все невыносимее. Цветут и множатся фермы автогенерируемых сайтов с говнотекстами, да простят меня дамы. Из-за них невозможно найти даже технические материалы, не говоря про обыкновенные. Но я бы так не переживал про поиск технических материалов, если бы в них были корректные ссылки. Ссылки дохнут как мухи и, читая пост годичной давности в форуме или блоге, нет почти никаких надежд перейти по указанным ссылкам.

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