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

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

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

У C и C++ программистов две головные боли в плане ошибок: утечки памяти и неопределённое поведение. И как вы догадались из названия, речь пойдёт о неопределённом поведении. И каком‑то «моём» компиляторе. Если точнее, то о наборе компиляторов и инструментах для их разработки, а именно LLVM. Почему «моём»? Потому что мы очень любим Clang, входящий в состав LLVM, и пользуемся им на постоянной основе.

А что если окажется, что простые знания на самом деле более нюансированные, а старые знакомые, такие как Double-checked locking, являются неоднозначными? Именно на такие мысли наталкивает изучение кода реальных проектов. Результаты этого исследования мы и рассмотрим в этой статье.

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

LLVM — open-source проект с огромной кодовой базой. Лучший из лучших, если говорить о качестве кода, учитывая его размеры и открытость. Ведь кому, как не разработчикам инструментов для компиляторов, лучше знать о возможностях языка и правильном их использовании. Их код всегда на высоте, а найти ошибки в нём всегда вызов для нашего анализатора, который мы принимаем.

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

Microsoft представили Garnet — проект кроссплатформенного быстрого кэш-хранилища с открытым исходным кодом, написанный на языке C#. Предлагаю расчехлить статический анализатор и посмотреть, какие ошибки и странности содержатся в исходном коде проекта.

В первой статье про qdEngine было рассмотрено 10 ошибок, выбранных плагином PVS-Studio. Однако есть ещё 10 багов, заслуживающих внимания. Как говорится, лучше учиться на чужих ошибках. Заодно они хорошо демонстрируют возможности PVS-Studio в выявлении разнообразнейших ошибочных паттернов.

ReactOS — это проект, где победу над регрессией, появление новой фичи или её рабочего прототипа празднуют так громко, что FOSS‑сообществу приходится отвлекаться от переписывания всего на Rust и полемик о systemd. В последний раз мы проверяли ReactOS в 2013 году, почти одиннадцать лет назад. Проверка была неточной ввиду неполного понимания структуры папок, из‑за чего в поле видимости PVS‑Studio оставались компоненты Wine. Пришло время освежить память и провести новую проверку, учитывая опыт предыдущей недоработки.

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

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

Баги, которые удалось найти в движке qdEngine, оказались весьма разнообразны, поэтому не хочется мешать всё в кучу в одной публикации. Читатели могут упустить интересные темы, связанные с написанием качественного кода. Поэтому разбор проекта выйдет в виде серии публикаций, первая из которых посвящается наиболее интересным срабатываниям с точки зрения плагина PVS-Studio.

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

Apache NetBeans — одна из первых IDE для Java, поддержка которой не прекращается на протяжении почти 30 лет. Совсем недавно вышла 21-я версия. Мы решили проверить исходный код такого долгожителя и выбрали наиболее интересные ошибки, которые разберём в этой статье.

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

Реальный "баг", баг в коде или невнимательность — всё это может повлиять на ваш проект и привести к самым разным последствиям. В этой статье собран ряд масштабных и интересных багов. Время учиться на чужих ошибках!

Вы когда-нибудь интересовались игровыми движками, написанными на Java? В этой статье мы рассмотрим и проверим на наличие ошибок в исходном коде один из популярных игровых движков — jMonkeyEngine. Возможно, мы даже узнаем, почему игры пишутся на C# и C++, а не на Java.

Как часто вам приходится сталкиваться с конструкцией sizeof(array)/sizeof(array[0]) для определения размера массива? Очень надеюсь, что не часто, ведь на дворе уже 2024 год. В заметке поговорим о недостатках конструкции, откуда она берётся в современном коде и как от неё наконец избавиться.