В целом я согласен, что специализированные самописные классы могут быть эффективнее их стандартных аналогов. Однако, не надо быть прям категоричным в этом. Есть смысл оптимизировать узкие места по необходимости, а не сразу писать всё своё :). Во-первых, своё может получиться куда менее надёжным. Во-вторых, эффективность многих встроенных классов значительно выросла, и они куда эффективнее, чем 10-20 лет назад. См. личную историю на тему std::string здесь (Вредный совет N50. Не верь в эффективность std::string).

Да )

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

Вот ещё багов :)

Проверка игрового движка qdEngine, часть третья: дополнительная десятка багов

Проверка игрового движка qdEngine, часть третья: дополнительная десятка багов

Не весь код можно не трогать. Статья о том, что статический анализ помогает начать рефакторинг. Анализатор даёт и повод и отправную точку для этого. А старый код он вот такой, да... У меня нет иллюзий на тему того, какой код скрывают недра реальных проектов :)

Проверка игрового движка qdEngine, часть вторая: упрощение C++ кода

Почему?

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

Я тоже допускаю опечатки :) Fixed

Я стараюсь учить в статьях хорошему :)

Реальный код реального проекта :). Это только в книгах всё идеально :)

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

Дэвид Парнас и Пол Клементс (David Parnas and Paul Clements)

Актуален код или нет, особенного значения не имеет :). Главное, он исторически интересен, даёт возможность поговорить про статический анализ и рефакторинг (про это будет в следующих частях). За идеи по проверке спасибо, передам коллегам подумать.

Тогда можно убрать static. Всё равно ведь есть интерфейс её дёргать из вне.

Ловите ленивого! :)

P.S. Системы разные бывают. Настройки систем бывают разные. Код может заимствоваться в другие приложения для других систем.

P.P.S. Впрочем, продолжайте. Больше подобного кода, больше спрос на статические анализаторы кода :) Спасибо.

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

«Есть всего два типа языков программирования: те, на которые люди всё время ругаются, и те, которые никто не использует» Bjarne Stroustrup
:)

В любом случае можно испортить свою память. Это может иметь весьма печальные последствия.

Причём здесь это. Записывая по случайному адресу можно испортить данные самого приложения.

Такое может быть в некоторых приложениях.

Это обсуждают. Я видел такие проверки. Значит стоит. :)