Я регулярно общаюсь с потенциальными пользователями, озабоченными ошибками в программах на языке Си++. Их озабоченность выражается в том, что они пробуют инструмент PVS-Studio и начинают писать о том, что при испытаниях что-то подозрительно мало ошибок было найдено. И хотя, вроде чувствуется, что инструмент им интересен, их реакция полна скептицизма.
Константин Книжник: статический анализ, взгляд со стороныTatyanazaxarova
Статья представляет интервью, взятое у Константина Книжника, сотрудником компании "Системы программной верификации" Андреем Карповым. Затронуты вопросы статического анализа кода, актуальность решений в этой области, а также перспективы использования статического анализа при разработке параллельных приложений.
VivaMP, система выявления ошибок в коде параллельных программ на языке С++, и...Tatyanazaxarova
В статье приводятся результаты исследований ошибок, которые допускают программисты, использующие С++ и OpenMP. Для автоматического обнаружения этих ошибок предлагается использование статического анализа. Описывается интегрирующийся в среду Visual Studio анализатор VivaMP, реализующий поставленную задачу.
Трудности сравнения анализаторов кода или не забывайте об удобстве использованияTatyanazaxarova
Желание пользователей сравнить между собой разные анализаторы кода понятно и естественно. Однако реализовать это желание совсем не так просто как может показаться на первый взгляд. Дело в том, что непонятно какие конкретно факторы между собой сравнивать.
Статья рассказывает о новом направлении в развитии статических анализаторов кода - верификации параллельных программ. В статье рассказывается о нескольких статических анализаторах, которые могут претендовать на звание "Parallel Lint".
Регулярное использование статического анализа кода в командной разработкеTatyanazaxarova
Технологии статического анализа кода применяются в компаниях со зрелыми процессами разработки программного обеспечения. Однако уровень применения и внедрения в процесс разработки инструментов анализа кода может быть различным. Начиная от ручного запуска анализатора "время от времени" или при поиске трудноуловимых ошибок, и кончая ежедневным автоматическим запуском или запуском при добавлении нового исходного кода в систему контроля версий.
В статье рассмотрены различные уровни использования технологий статического анализа кода в командной разработке, показано как "перевести" процесс с одного уровня на другой. В качестве примера в статье используется разрабатываемый авторами анализатор кода PVS-Studio.
Статический анализ кода: современный взглядAndrey Karpov
Статический анализ - это методология выявления ошибок в исходном тексте программы, основанная на просмотре кода программистом, помеченного статическим анализатором там, где потенциально может находиться ошибка. Многие относятся к статическому анализу как к устаревшему и не актуальному методу. Действительно, существует ряд моментов, из-за которых кажется, что статический анализ приносил пользу раньше, когда средства разработки были намного менее функциональны. Однако если отбросить устаревшее, то оказывается, что методология статического анализа по-прежнему позволят существенно сократить цену устранения многих дефектов, за счет их обнаружения еще на стадии конструирования (кодирования). Более того, развитие языков, появление таких технологий программирования как OpenMP, увеличение среднего размера проекта делают применение статических анализаторов все более привлекательным для контроля качества проекта.
Разница в подходах анализа кода компилятором и выделенным инструментомTatyanazaxarova
У компилятора и сторонних инструментов статического анализа кода есть общая задача - выявление опасных фрагментов кода. Однако существует существенная разница в том, анализ какого типа они осуществляют. Я попробую на примере компилятора Intel C++ и анализатора PVS-Studio продемонстрировать различия подходов, и пояснить, чем они вызваны.
Константин Книжник: статический анализ, взгляд со стороныTatyanazaxarova
Статья представляет интервью, взятое у Константина Книжника, сотрудником компании "Системы программной верификации" Андреем Карповым. Затронуты вопросы статического анализа кода, актуальность решений в этой области, а также перспективы использования статического анализа при разработке параллельных приложений.
VivaMP, система выявления ошибок в коде параллельных программ на языке С++, и...Tatyanazaxarova
В статье приводятся результаты исследований ошибок, которые допускают программисты, использующие С++ и OpenMP. Для автоматического обнаружения этих ошибок предлагается использование статического анализа. Описывается интегрирующийся в среду Visual Studio анализатор VivaMP, реализующий поставленную задачу.
Трудности сравнения анализаторов кода или не забывайте об удобстве использованияTatyanazaxarova
Желание пользователей сравнить между собой разные анализаторы кода понятно и естественно. Однако реализовать это желание совсем не так просто как может показаться на первый взгляд. Дело в том, что непонятно какие конкретно факторы между собой сравнивать.
Статья рассказывает о новом направлении в развитии статических анализаторов кода - верификации параллельных программ. В статье рассказывается о нескольких статических анализаторах, которые могут претендовать на звание "Parallel Lint".
Регулярное использование статического анализа кода в командной разработкеTatyanazaxarova
Технологии статического анализа кода применяются в компаниях со зрелыми процессами разработки программного обеспечения. Однако уровень применения и внедрения в процесс разработки инструментов анализа кода может быть различным. Начиная от ручного запуска анализатора "время от времени" или при поиске трудноуловимых ошибок, и кончая ежедневным автоматическим запуском или запуском при добавлении нового исходного кода в систему контроля версий.
В статье рассмотрены различные уровни использования технологий статического анализа кода в командной разработке, показано как "перевести" процесс с одного уровня на другой. В качестве примера в статье используется разрабатываемый авторами анализатор кода PVS-Studio.
Статический анализ кода: современный взглядAndrey Karpov
Статический анализ - это методология выявления ошибок в исходном тексте программы, основанная на просмотре кода программистом, помеченного статическим анализатором там, где потенциально может находиться ошибка. Многие относятся к статическому анализу как к устаревшему и не актуальному методу. Действительно, существует ряд моментов, из-за которых кажется, что статический анализ приносил пользу раньше, когда средства разработки были намного менее функциональны. Однако если отбросить устаревшее, то оказывается, что методология статического анализа по-прежнему позволят существенно сократить цену устранения многих дефектов, за счет их обнаружения еще на стадии конструирования (кодирования). Более того, развитие языков, появление таких технологий программирования как OpenMP, увеличение среднего размера проекта делают применение статических анализаторов все более привлекательным для контроля качества проекта.
Разница в подходах анализа кода компилятором и выделенным инструментомTatyanazaxarova
У компилятора и сторонних инструментов статического анализа кода есть общая задача - выявление опасных фрагментов кода. Однако существует существенная разница в том, анализ какого типа они осуществляют. Я попробую на примере компилятора Intel C++ и анализатора PVS-Studio продемонстрировать различия подходов, и пояснить, чем они вызваны.
Выполняет анализ кода на языках: C, C++, C++/CLI, C++/CX, C#. Plugin для Visual Studio 2010-2015. Интеграция с SonarQube, QtCreator, CLion, Eclipse CDT, Anjuta DevStudio и т.д. Быстрый старт (мониторинг компиляции). Прямая интеграция анализатора в системы автоматизации сборки и утилита BlameNotifier (рассылка писем). Режим автоматического анализа изменённых файлов. Почему нужны анализаторы кода?
Использование анализатора PVS-Studio в процессе инкрементальной сборки в Micr...Tatyanazaxarova
Одним из нововведений в последних версиях MSBuild/Visual Studio для компиляторов Visual C++ стала новая система минимальной сборки (также известная как инкрементная сборка), основанная на отслеживании зависимостей между входными и выходными данными при работе компилятора и позволяющая осуществлять пересборку только для файлов, затронутых модификацией исходного кода или не имеющих связанных с ними выходных объектных файлов. В отличие от старой методики минимальной пересборки, завязанной на генерируемые компилятором cl.exe файлы состояний (idb-файлы, Minimal Rebuild Dependancy Database, ключ /Gm) и обладавшей рядом недостатков (как например затруднённость распараллеливания сборки из-за конфликтов доступа и отсутствие прямого отслеживания выходных объектный файлов), новая система не зависит от типа используемых сборочных инструментов (может использоваться как для компиляции, так и для линковки) и имеет открытый API. Данная новинка позволила интегрировать проверку кода анализатором PVS-Studio в процесс разработки на C/C++ с использованием инкрементных пересборок для последней версии Visual Studio 2010. Эта возможность появилась в версии PVS-Studio 4.30.
PVS-Studio научился следить за тем, как вы программируетеTatyanazaxarova
В PVS-Studio появился режим работы, который поможет максимально рано выявлять ошибки и опечатки. Анализатор запускается сразу после компиляции файлов и если что-то не так, покраснеет от стыда за ваш код. Фича доступна на данный момент только для пользователей Visual Studio 2010.
Урок 8. Статический анализ для выявления 64-битных ошибокTatyanazaxarova
Статический анализ кода - методология выявления ошибок в программном коде, основанная на просмотре программистом участков кода, помеченных статическим анализатором. Помеченные участки кода с большой вероятностью содержат ошибки определенного типа.
Статический анализ кода: борьба с удорожанием ошибокAndrey Karpov
Нет смысла говорить, что "надо писать код без ошибок". Ошибки были, есть и будут. Все хорошо понимают, что ошибки следует исправлять. Люди забывают, что ошибка должна быть исправлена с минимальными временными и денежными затратами!
Как создать качественный статический анализаторAndrey Karpov
В докладе я расскажу о методиках достижения высокого качества продукта, которые наша команда использует при разработке статического анализатора. Упор сделаю на особенности разработки, а также на повышение качества именно анализа, то есть поиска реальных ошибок и потенциальных уязвимостей в коде.
Отладка и оптимизация многопоточных OpenMP-программTatyanazaxarova
Задача знакомства программистов с областью разработки параллельных приложений становится все актуальней. Данная статья является кратким введением в создание многопоточных приложений, основанных на технологии OpenMP. Описаны подходы к отладке и оптимизации параллельных приложений.
Неудачная попытка сравнить PVS-Studio (VivaMP) и Intel C/C++ ("Parallel Lint")Tatyanazaxarova
Изначально статья должна была носить название "Сравнение диагностических возможностей PVS-Studio (VivaMP) и Intel C/C++ Compiler ("Parallel Lint"). Отсутствие на данный момент достаточного количества информации о "Parallel Lint" ограничило возможности автора, и статья представляет собой предварительный вариант сравнения. Полный вариант статьи с корректным сравнением будет доступен читателю в будущем. Обратите внимание, что содержание статьи актуально на момент публикации. В дальнейшем возможно изменение диагностических возможностей обоих продуктов.
Интервью с Дмитрием Вьюковым – автором верификатора Relacy Race Detector (RRD)Tatyanazaxarova
Интервью с Дмитрием Вьюковым - автором инструмента Relacy Race Detector (RRD) для верификации параллельных приложений. В статье вы узнаете об истории создания RRD, его основных возможностях, а также о некоторых других аналогичных инструментах и их отличии от RRD.
Язык C++ и инфраструктура вокруг него продолжает активно развиваться, что делает этот язык одним из самых эффективных инструментов в настоящее время. Хочется выделить три фактора, делающие язык C++ сейчас столь привлекательным. Первое: нововведения в стандарт языка, позволяющие писать эффективный код. Второе: зрелость инструментов разработки и увеличение скорости сборки проектов. Третье: зрелось вспомогательного инструментария, позволяющие контролировать качество кода и другие аспекты жизненного цикла проекта. Этот доклад - ода языку программирования C++!
А существуют ли в реальности 64-битные ошибки?Tatyanazaxarova
Я часто слышу в различных интерпретациях фразу "Приведенные примеры показывают не код, неправильный в плане переносимости на х64 системы, а код, неправильный сам по себе". Захотелось немного пообсуждать и пофилософствовать в блоге на эту тему. Просьба отнестись к этой записи с долей юмора.
Что могут статические анализаторы, чего не могут программисты и тестировщикиAndrey Karpov
Одной из технологий выявления ошибок на ранних этапах является статический анализ кода. К сожалению, ряд инструментов реализуют анализ весьма поверхностно, что снижает доверие к методологии статического анализа в целом. Некоторые программисты начинают думать, что анализ кода — это нечто, базирующееся на регулярных выражениях и они сами легко найдут такие ошибки. На самом деле всё гораздо сложнее и интересней. Более того, многие ошибки невероятно сложно найти, если не использовать инструменты статического анализа кода. И в этом докладе будет продемонстрировано множество таких случаев. Послушав доклад, вы взглянете на статический анализ совсем по-новому. Дополнительно будет рассказано с чего начать, если вы захотите внедрить инструмент статического анализа в уже существующий процесс разработки.
Здесь вы найдёте 60 вредных советов для программистов и пояснение, почему они вредные. Всё будет одновременно в шутку и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.
Статический анализ исходного кода на примере WinMergeTatyanazaxarova
Сегодня я хочу посвятить пост тематике, почему инструменты анализа исходного кода полезны вне зависимости от уровня знаний и опыта программиста. А польза такого анализа будет продемонстрирована на примере инструмента, который известен всем программистам - WinMerge.
Выполняет анализ кода на языках: C, C++, C++/CLI, C++/CX, C#. Plugin для Visual Studio 2010-2015. Интеграция с SonarQube, QtCreator, CLion, Eclipse CDT, Anjuta DevStudio и т.д. Быстрый старт (мониторинг компиляции). Прямая интеграция анализатора в системы автоматизации сборки и утилита BlameNotifier (рассылка писем). Режим автоматического анализа изменённых файлов. Почему нужны анализаторы кода?
Использование анализатора PVS-Studio в процессе инкрементальной сборки в Micr...Tatyanazaxarova
Одним из нововведений в последних версиях MSBuild/Visual Studio для компиляторов Visual C++ стала новая система минимальной сборки (также известная как инкрементная сборка), основанная на отслеживании зависимостей между входными и выходными данными при работе компилятора и позволяющая осуществлять пересборку только для файлов, затронутых модификацией исходного кода или не имеющих связанных с ними выходных объектных файлов. В отличие от старой методики минимальной пересборки, завязанной на генерируемые компилятором cl.exe файлы состояний (idb-файлы, Minimal Rebuild Dependancy Database, ключ /Gm) и обладавшей рядом недостатков (как например затруднённость распараллеливания сборки из-за конфликтов доступа и отсутствие прямого отслеживания выходных объектный файлов), новая система не зависит от типа используемых сборочных инструментов (может использоваться как для компиляции, так и для линковки) и имеет открытый API. Данная новинка позволила интегрировать проверку кода анализатором PVS-Studio в процесс разработки на C/C++ с использованием инкрементных пересборок для последней версии Visual Studio 2010. Эта возможность появилась в версии PVS-Studio 4.30.
PVS-Studio научился следить за тем, как вы программируетеTatyanazaxarova
В PVS-Studio появился режим работы, который поможет максимально рано выявлять ошибки и опечатки. Анализатор запускается сразу после компиляции файлов и если что-то не так, покраснеет от стыда за ваш код. Фича доступна на данный момент только для пользователей Visual Studio 2010.
Урок 8. Статический анализ для выявления 64-битных ошибокTatyanazaxarova
Статический анализ кода - методология выявления ошибок в программном коде, основанная на просмотре программистом участков кода, помеченных статическим анализатором. Помеченные участки кода с большой вероятностью содержат ошибки определенного типа.
Статический анализ кода: борьба с удорожанием ошибокAndrey Karpov
Нет смысла говорить, что "надо писать код без ошибок". Ошибки были, есть и будут. Все хорошо понимают, что ошибки следует исправлять. Люди забывают, что ошибка должна быть исправлена с минимальными временными и денежными затратами!
Как создать качественный статический анализаторAndrey Karpov
В докладе я расскажу о методиках достижения высокого качества продукта, которые наша команда использует при разработке статического анализатора. Упор сделаю на особенности разработки, а также на повышение качества именно анализа, то есть поиска реальных ошибок и потенциальных уязвимостей в коде.
Отладка и оптимизация многопоточных OpenMP-программTatyanazaxarova
Задача знакомства программистов с областью разработки параллельных приложений становится все актуальней. Данная статья является кратким введением в создание многопоточных приложений, основанных на технологии OpenMP. Описаны подходы к отладке и оптимизации параллельных приложений.
Неудачная попытка сравнить PVS-Studio (VivaMP) и Intel C/C++ ("Parallel Lint")Tatyanazaxarova
Изначально статья должна была носить название "Сравнение диагностических возможностей PVS-Studio (VivaMP) и Intel C/C++ Compiler ("Parallel Lint"). Отсутствие на данный момент достаточного количества информации о "Parallel Lint" ограничило возможности автора, и статья представляет собой предварительный вариант сравнения. Полный вариант статьи с корректным сравнением будет доступен читателю в будущем. Обратите внимание, что содержание статьи актуально на момент публикации. В дальнейшем возможно изменение диагностических возможностей обоих продуктов.
Интервью с Дмитрием Вьюковым – автором верификатора Relacy Race Detector (RRD)Tatyanazaxarova
Интервью с Дмитрием Вьюковым - автором инструмента Relacy Race Detector (RRD) для верификации параллельных приложений. В статье вы узнаете об истории создания RRD, его основных возможностях, а также о некоторых других аналогичных инструментах и их отличии от RRD.
Язык C++ и инфраструктура вокруг него продолжает активно развиваться, что делает этот язык одним из самых эффективных инструментов в настоящее время. Хочется выделить три фактора, делающие язык C++ сейчас столь привлекательным. Первое: нововведения в стандарт языка, позволяющие писать эффективный код. Второе: зрелость инструментов разработки и увеличение скорости сборки проектов. Третье: зрелось вспомогательного инструментария, позволяющие контролировать качество кода и другие аспекты жизненного цикла проекта. Этот доклад - ода языку программирования C++!
А существуют ли в реальности 64-битные ошибки?Tatyanazaxarova
Я часто слышу в различных интерпретациях фразу "Приведенные примеры показывают не код, неправильный в плане переносимости на х64 системы, а код, неправильный сам по себе". Захотелось немного пообсуждать и пофилософствовать в блоге на эту тему. Просьба отнестись к этой записи с долей юмора.
Что могут статические анализаторы, чего не могут программисты и тестировщикиAndrey Karpov
Одной из технологий выявления ошибок на ранних этапах является статический анализ кода. К сожалению, ряд инструментов реализуют анализ весьма поверхностно, что снижает доверие к методологии статического анализа в целом. Некоторые программисты начинают думать, что анализ кода — это нечто, базирующееся на регулярных выражениях и они сами легко найдут такие ошибки. На самом деле всё гораздо сложнее и интересней. Более того, многие ошибки невероятно сложно найти, если не использовать инструменты статического анализа кода. И в этом докладе будет продемонстрировано множество таких случаев. Послушав доклад, вы взглянете на статический анализ совсем по-новому. Дополнительно будет рассказано с чего начать, если вы захотите внедрить инструмент статического анализа в уже существующий процесс разработки.
Здесь вы найдёте 60 вредных советов для программистов и пояснение, почему они вредные. Всё будет одновременно в шутку и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.
Статический анализ исходного кода на примере WinMergeTatyanazaxarova
Сегодня я хочу посвятить пост тематике, почему инструменты анализа исходного кода полезны вне зависимости от уровня знаний и опыта программиста. А польза такого анализа будет продемонстрирована на примере инструмента, который известен всем программистам - WinMerge.
Реклама PVS-Studio - статический анализ кода на языке Си и Си++Andrey Karpov
Этот документ рекламирует статический анализатор PVS-Studio. Описывается, как использование PVS-Studio уменьшит количество ошибок в коде проекта на языке C/C++/C++11 и сократит затраты на тестирование, отладку и сопровождение кода. Приводится большое количество примеров ошибок, найденных анализатором в различных Open-Source проектах. Документ описывает PVS-Studio на момент версии 4.38 от 12 октября 2011 и, как следствие, не отражает возможности следующих версий. Чтобы познакомиться с новыми возможностями, предлагаем посетить сайт продукта <a>http://www.viva64.com</a> или поискать обновленный вариант этой статьи.
В статье описаны технологии тестирования, используемые при разработке статического анализатора кода PVS-Studio. Разработчики инструмента для программистов делятся принциами тестирования собственного программного продукта, которые могут быть интересны разработчикам аналогичных пакетов обработки текстовых данных или исходных кодов.
Андрей Солоной "Как людям бизнеса работать с программистами"Startup_Technologies
Эксперт Startup Weekend, ведущий .NETразработчик и архитектор с большим опытом, ментор в EffectiveSoft Андрей Солоной выступил на Стартап-школе с мастер-классом: "Как людям бизнеса работать с программистами"
Поиск ловушек в Си/Си++ коде при переносе приложений под 64-битную версию Win...Tatyanazaxarova
В результате появления на рынке персональных компьютеров 64-битных процессоров перед разработчиками программ возникает задача переноса старых 32-битных приложений на новую платформу. После переноса кода приложения высока вероятность его некорректной работы. В статье рассмотрены вопросы, связанные с верификацией и тестированием программного обеспечения. Обозначены сложности, с которыми может столкнуться разработчик 64-битных Windows приложений и пути их преодоления.
В этот раз победу одержало добро. А вернее, исходные коды проекта Chromium. Chromium - один из лучших проектов, который мы проверяли с помощью PVS-Studio.
Трепещи, мир! Мы выпустили PVS-Studio 4.00 с бесплатным анализатором общего н...Tatyanazaxarova
Предлагаем вниманию программистов новый инструмент для поиска ошибок в исходном коде приложений на языке Си/Си++. В рамках анализатора PVS-Studio реализован новый набор правил общего назначения. Эта функциональность на данный момент является бесплатной.
Тестирование параллельного программного обеспечения представляет собой более сложную задачу по сравнению с тестированием последовательной программы. Программист должен знать о подводных камнях при тестировании параллельного кода, имеющихся методологиях и инструментарии.
Облегчаем процесс разработки с помощью статического анализа кода: Наш опытAndrey Karpov
Статический анализ кода является очень полезным DevOps-средством, помогающим программистам при разработке крупных (и не только) проектов. К сожалению, с ним знакомы далеко не все программисты, а те, кто знаком — часто вспоминают их как «старые добрые lint'еры».
В своем докладе автор покажет, на что на самом деле способен современный статический анализ, а также расскажет о опыте внедрения анализатора в процесс разработки Unreal Engine 4.
Доклад будет полезен программистам всех уровней, руководителям, а также DevOps-специалистам, желающим повысить качество их проектов.
Как уменьшить вероятность ошибки на этапе написания кода. Заметка N1.Tatyanazaxarova
Я добрался до кода широко известного клиента мгновенных сообщений Miranda IM. Вместе с различными плагинами это достаточно большой проект, размер которого составляет около 950 тысяч строк кода на C и C++. И, как в любом солидном проекте с историей развития, в нем имеется немалое количество ошибок и опечаток.
32 подводных камня OpenMP при программировании на Си++Tatyanazaxarova
С распространением многоядерных систем задача параллельного программирования становится все более и более актуальной. Данная область, однако, является новой даже для большинства опытных программистов. Существующие компиляторы и анализаторы кода позволяют находить некоторые ошибки, возникающие при разработке параллельного кода. Многие ошибки никак не диагностируются. В данной статье приводится описание ряда ошибок, приводящих к некорректному поведению параллельных программ, созданных на основе технологии OpenMP.
Виды QA: Всё что вы не знали и боялись спроститьGoIT
19.02.2015 состоялось очередное событие, посвященное тематике Тестирования ПО.
Встреча помогла участникам
• разобраться в видах QA;
• получить информацию о «подводных» камнях каждого из направлений;
• узнать о специфике работы тестеровщика;
• перенять опыт тестировщиков с многолетним стажем;
• узнать о нововведениях в мире QA;
• выбрать свой путь развития в тестировании.
Спикерами выступили:
Александр Майданюк – QA Lead, Manager, QA Consultant и Trainer. Занимает позицию Head
of Quality Assurance Solution в Ciklum. Эксперт и судья QA секции чемпионатов UA Web
Challenge. Соучредитель Киевского Клуба тестировщика QA Club.
Николай Ковш – QA Engineer в Ciklum. Является ярким примером свитчера - человека,
который сменил область деятельности. Со-организатор ивентов в QA Club - самом большом
киевском сообществе тестировщиков. Николай расскажет, почему тестировщику важно
научиться программировать.
Марина Шевченко – Mobile QA Engineer в Ciklum. QA з досвідом тестування веб, дестопних
та мобільних додатків. Співорганізатор заходів в QA Club – найбільшій київській спільності
тестувальників.
Урок 27. Особенности создания инсталляторов для 64-битного окруженияTatyanazaxarova
При разработке 64-битной версии приложения дополнительное внимание стоит уделить и вопросу дистрибуции программы. Ведь при установке на 64-битной операционной системе есть несколько нюансов, забыв о которых можно получить неработающий инсталляционный пакет.
После компиляции программы в 64-битном режиме она начинает потреблять большее количество памяти, чем ее 32-битный вариант. Часто это увеличение почти незаметно, но иногда потребление памяти может возрастать в 2 раза.
Урок 25. Практическое знакомство с паттернами 64-битных ошибокTatyanazaxarova
Данная статья содержит различные примеры 64-битных ошибок, собранные в демонстрационном примере PortSample. Однако, начиная с версии PVS-Studio 3.63, вместо PortSample в дистрибутив PVS-Studio включается более новая версия примеров, которая называется OmniSample. Поэтому некоторые скриншоты в статье не соответствуют актуальному состоянию дел.
Мы закончили рассмотрение паттернов 64-битных ошибок. Последнее на чем мы остановимся в связи с этими ошибками, является то, как они могут проявляться в программах.
Сам по себе рост размера структур не является ошибкой, но может приводить к потреблению необоснованного количества памяти и в результате к замедлению скорости работы программы. Будем рассматривать данный паттерн не как ошибку, но как причину неэффективности 64-битного кода.
Процессоры работают эффективнее, когда имеют дело с правильно выровненными данными. А некоторые процессоры вообще не умеют работать с не выровненными данными.
Генерирование и обработка исключений с участием целочисленных типов не является хорошей практикой программирования на языке Си++. Для этих целей следует использовать более информативные типы, например классы, производные от класса std::exception.
Урок 19. Паттерн 11. Сериализация и обмен даннымиTatyanazaxarova
Важным элементом переноса программного решения на новую платформу является преемственность к существующим протоколам обмена данными. Необходимо обеспечить чтение существующих форматов проектов, осуществлять обмен данными между 32-битными и 64-битными процессами и так далее.
Надеемся, вы уже успели отдохнуть от 13 урока и теперь сможете рассмотреть еще один важный паттерн ошибок, связанный с арифметическими выражениями, в которых участвуют типы различной размерности.
Урок 16. Паттерн 8. Memsize-типы в объединенияхTatyanazaxarova
Особенностью объединения (union) является то, что для всех элементов (членов) объединения выделяется одна и та же область памяти, то есть они перекрываются. Хотя доступ к этой области памяти возможен с использованием любого из элементов, элемент для этой цели должен выбираться так, чтобы полученный результат был осмысленным.
Большое количество ошибок при миграции на 64-битные системы связано с изменением соотношения между размером указателя и размером обычных целых. В среде с моделью данных ILP32 обычные целые и указатели имеют одинаковый размер. К сожалению, 32-битный код повсеместно опирается на это предположение. Указатели часто приводятся к int, unsigned, long, DWORD и другим неподходящим типам.
Мы специально выбрали номер "тринадцать" для этого урока, поскольку ошибки, связанные с адресной арифметикой в 64-битных системах, являются наиболее коварными. Надеемся, число 13 заставит вас быть внимательнее.
Урок 10. Паттерн 2. Функции с переменным количеством аргументовTatyanazaxarova
Классическими примерами, приводимыми во многих статьях по проблемам переноса программ на 64-битные системы, является некорректное использование функций printf, scanf и их разновидностей.
В некачественном коде часто встречаются магические числовые константы, наличие которых опасно само по себе. При миграции кода на 64-битную платформу эти константы могут сделать код неработоспособным, если участвуют в операциях вычисления адреса, размера объектов или в битовых операциях.
Исправление всех ошибок компиляции и предупреждений не будет означать работоспособность 64-битного приложения. И именно описанию и диагностике 64-битных ошибок будет посвящена основная часть уроков. Также не надейтесь на помощь ключа /Wp64, который многими часто без оснований преподносится при обсуждениях в форумах как чудесное средство поиска 64-битных ошибок.
Хочется сразу предупредить читателя, что невозможно всесторонне описать процесс сборки 64-битного приложения. Настройки любого проекта достаточно уникальны, поэтому к адаптации настроек для 64-битной системы всегда надо подходить внимательно. В уроке будут описаны только общие шаги, которые важны для любого проекта. Эти шаги подскажут вам с чего начать процесс.
Вначале следует убедиться, что используемая вами редакция Visual Studio позволяет собирать 64-битный код. Если вы планируете разрабатывать 64-битные приложения с использованием последней версии (на момент написания курса) Visual Studio 2008, то следующая таблица поможет определить, какая из редакций Visual Studio вам необходима.
PVS-Studio, решение для разработки современных ресурсоемких приложенийTatyanazaxarova
Инструмент PVS-Studio
набор правил Viva64 для анализа 64-битных приложений;
набор правил VivaMP для анализа параллельных приложений;
набор правил для анализа общего назначения.
Лицензионная и ценовая политика PVS-Studio
Информация о компании ООО «СиПроВер»
Мы все допускаем ошибки при программировании и тратим массу времени на их устранение.
Один из методов который позволяет быстро диагностировать дефекты – статический анализ исходного кода.
1. Статический анализ и ROI
Автор: Андрей Карпов
Дата: 06.06.2011
Я регулярно общаюсь с потенциальными пользователями, озабоченными ошибками в
программах на языке Си++. Их озабоченность выражается в том, что они пробуют инструмент PVS-
Studio и начинают писать о том, что при испытаниях что-то подозрительно мало ошибок было
найдено. И хотя, вроде чувствуется, что инструмент им интересен, их реакция полна скептицизма.
И начинается общение, где я пытаюсь убедить какой хороший и полезный продукт PVS-Studio, и
как он мог бы быть полезен компании. На что получаю критику своих обоснований и колкие
замечания по работе анализатора и выдаваемым ложным предупреждениям. В общем, идёт
нормальная маркетинговая работа.
В ходе общения, мной был написан развернутый ответ, который оппонент по дискуссии
предложил мне оформить в виде статьи. Что я и делаю. Надеемся услышать комментарии
касательно оценки пользы, которую могут принести инструменты статического анализа кода. Хотя
статья написана с ориентацией на PVS-Studio, приведенные в ней расчеты, как мне кажется, будут
интересны вне зависимости от того о каком инструменте статического анализа говорить.
----
Текст, приведенный ниже, отвечает на следующий фрагмент письма:
...
Еще найдены порядка 40 (сорока) реальных дефектов - в основном, это недопиленный
копипаст.
В связи с этим есть вопрос: что мы получим от интеграции совсем не дешевой программы в
процесс разработки ПО, в коде которого программа выявляет настолько мало дефектов? Да,
я понимаю, что мы быстрее обнаружим свежепосаженную ошибку, но ведь их так мало.
...
Итак, взглянем на инструменты статического анализа с точки зрения возврата инвестиций (ROI).
Возьмем среднего программиста, который основную часть рабочего времени тратит на
разработку программного обеспечения на языке Си++. Мне такого человека очень легко
представить, поскольку я сам активно программировал и программирую. Предположим, что он
использует ночной запуск статического анализатора кода. Также предположим, что в таком
режиме использования и при среднем темпе программирования, анализатор может обнаружить
два дефекта в коде, допускаемых человеком в неделю.
Говорю это не абстрактно, а опираясь на собственный опыт. Я сейчас только в пол силы работаю с
кодом, но почти каждую неделю замечаю ляп в своем собственном коде, благодаря ночному
2. анализу. Обычно это мелочь, которая все равно бы выявилась при написании теста или запуске
регрессионных тестов, но изредка попадается и более серьезное. Пример дефекта, найденного
PVS-Studio в собственном коде буквально на днях:
bool staticSpecification = IsStaticSpecification(sspec);
bool virtualSpecification = IsVirtualSpecification(sspec);
bool externSpecification = IsVirtualSpecification(sspec);
То, что я пишу статьи о вреде Copy-Paste, вовсе не мешает мне самому сделать подобную ошибку.
Я тоже человек, я тоже копирую фрагменты кода и тоже иногда ошибаюсь. Выловить ошибку,
подобную приведенной выше, очень непросто. На практике она привела бы к тому, что в
некоторых редких случаях анализатор выдал бы ложное предупреждение на некоторые
конструкции кода. Составить ручной тест мне вряд ли бы удалось для этой редкой ситуации
(собственно и не удалось, раз я заложил этот код в SVN). Ошибка коварна тем, что если на неё
пожалуется кто-то из пользователей, то я бы искал её не менее пары часов, да ещё бы просил
пользователя прислать *.i файл. Но мы отвлеклись.
Если программист пишет код регулярнее, чем это делаю я, то 2 полезных предупреждения от
анализатора в неделю - это естественное количество. Итого за год анализатор может выдать
2*4*11 = 88 полезных предупреждений. Временем исправления подобных дефектов и
подавлением ложных предупреждений можно практически пренебречь. Тем не менее, все-таки
учтем их.
Пусть на 2 полезных исправления и 2 ложных срабатывания человек в неделю тратит 20 минут.
Итого в год на работу с анализатором кода будет потрачено: 20*4*11 = 880 минут. Или 15 часов.
Кажется, много пустой траты времени? Это очень мало, по сравнению с тем, что мы посчитаем
дальше.
Теперь рассмотрим цену устранения тех же дефектов, если они не обнаруживаются во время
ночных проверок анализатором кода.
60% из этих ошибок будет обнаружено самим программистом чуть позже при написании юнит-
тестов, самостоятельном предварительном тестировании или в процессе отладки других участков
кода. Будем считать, что поиск самой ошибки и её исправление в этом случае занимает около 15
минут, поскольку человек работает с недавно написанным кодом и хорошо в нём ориентируется.
Примером может быть ситуация, когда в каком-то диалоге программист обнаруживает текст,
который там быть не должен и выясняет, что он случайно вчера использовал x.empty() вместо
x.clear():
url_.empty();
if (status_text)
url_ = status_text;
Только не говорите, что исправление подобных ошибок это 1-2 минуты времени. Конкретно
исправление это вообще несколько секунд. Но нужно ещё найти нужное место, скомпилировать
3. исправленный код, проверить корректность исправления, возможно, заложить правки в SVN. Так
что пусть будет 15 минут.
Сразу отмечу, что ошибки такого рода обычно правятся на автомате и как бы не считаются
ошибками, поскольку нигде не учитываются.
35% ошибок обнаружатся на этапе тестирования. У этих ошибок более долгий жизненный цикл.
Вначале тестировщик локализует и воспроизводит проблему. Составляет и помещает описание
ошибки в баг-трекер. Программист находит и исправляет ошибку, после чего уведомляет
тестировщика о необходимости вновь проверить данный участок и закрыть ошибку. Суммарное
время, которое затратят вместе тестировщик и программист составит порядка 2-х часов.
Примером такой ошибки может быть некорректная работа с OPENFILENAME. Программисту может
повезти и он не увидит "кракозябры" в диалоге, а увидит их только тестер и то не каждый раз
(Гейзенбаг):
OPENFILENAME info = {0};
...
info.lpstrFilter = L"*.txt";
Осталось 5% незамеченных ошибок. То есть эти ошибки не обнаруживаются программистом и QA-
инженерами, но могут быть выявлены статическим анализатором кода.
Если взять и проверить ваш текущий проект с помощью PVS-Studio или другого статического
анализатора, то вы увидите как раз эти самые ненайденные 5% ошибок. Эти 5% и есть те самые 40
ошибок, о которых говорил потенциальный пользователь в ходе проб PVS-Studio.
Остальное 95% ошибок вы поправили сами ранее в процессе написания тестов, юнит-
тестирования, ручного тестирования и других методов.
Итак, у нас есть 5% ошибок, которые мы не можем найти и выпускаем с ними продукт. Из них 4%
могут вообще никогда не проявить себя и про них нет смысла говорить. Оставшийся 1% ошибок
может неожиданно проявить себя на стороне заказчика и доставить массу неприятностей.
Например, клиент хочет написать плагин к вашей системе, и программа падает из за подобного
кода:
bool ChromeFrameNPAPI::Invoke(...)
{
ChromeFrameNPAPI* plugin_instance =
ChromeFrameInstanceFromNPObject(header);
if (!plugin_instance && (plugin_instance->automation_client_.get()))
return false;
4. Вы так не делаете и всегда тестируете внешние интерфейсы? Молодцы. А вот у Google в Chromium
вот здесь не получилось. Так что зарекаться не стоит.
И если вам дорог клиент, и вы цените его, то вас ждут мучительные часы поиска дефекта и
переписки с клиентом. После чего вы ещё дополнительно будете вынуждены сделать для него
фикс или досрочно выпустить очередную версию. На подобные ошибки можно легко потратить
40 часов рабочего времени различных людей, не говоря о нервах.
Что, кто сказал "это неправда"? Вы никогда не сидели с одним коварнейшим багом целую
неделю? Тогда вы и не программировали никогда толком. :)
Посчитаем, сколько времени можно было сэкономить в течение года:
88 * 0.60 * 15 = 792 минуты
88 * 0.35 * 120 = 3696 минут
88 * 0.01 * 40 * 60 = 2212 минут
Итого, человек в течение года тратит на исправление некоторого подмножества собственных
ошибок: (792 + 3696 + 2212) / 60 = 112 часов.
Команда из 5 человек в течение года потратит на некоторые собственные ошибки около 560 часов
времени или 70 дней. С учетом оплачиваемых выходных, отпусков и болезней это приравнивается
к 4 месяцам работы одного абстрактного человека.
Выгодно или не выгодно использовать статический анализатор, зависит от зарплаты ваших
сотрудников.
Поскольку имеется в виду абстрактный человек (участвуют не только программисты), то возьмем
зарплату в 50 000 р. Учитывая налоги на зарплату, аренду помещения, покупку и амортизацию
компьютеров, премии, интернет, сок и прочее, то это число можно смело умножить как минимум
в 2 раза.
Получаем, что цена правки ошибок (не всех, но большинства) без использования статического
анализа составляет 100 000 * 4 = 400 000 рублей.
Если быстро находить эти же ошибки с помощью статического анализа кода, то цена их
исправления составит: 5 * (15 / 8) * 100 000 / 20 = 47 000 рублей.
Прибавим сюда стоимость покупки лицензия PVS-Studio на команду из 5 человек.
Итого цена исправлений ошибок с использованием статического анализатора составит (3 500
евро) * 40.5 + 47 000 = 189 000 рублей.
5. Итого, чистый PROFIT в год от использования статического анализатора PVS-Studio в команде из 5
программистов составляет:
400 000 - 189 000 = 211 000 рублей.
Цена исправления некоторых ошибок уменьшилась более чем в 2 раза. Думайте сами, решайте
сами, иметь или не иметь...
Да, еще замечу, что при расчетах я придерживался скромных позиций. На самом деле, я думаю,
инвестиции окупятся гораздо лучше. Хотелось показать, что даже при скромных расчетах, есть
прибыль. И только, пожалуйста, не пытайтесь упрекнуть меня в каких-то цифрах. В статье показан
подход к качественной оценке пользы, а не количественной.