Сохраняются ли концепции ускоренного практического программирования на C++ на примерах сегодня?

Вау нет.

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

Объектно-ориентированное программирование - это способ написания компонентов таким образом, чтобы они могли логически группировать действия, связанные с одной концепцией (т. Е. Все действия для «машины» или все действия для «кошки»). Это не значит, что его нельзя неправильно использовать для написания объектов спагетти, но, как говорится, вы можете писать COBOL на любом языке.

В качестве еще одного примера: в наши дни вполне возможно и принято писать для встроенных программных платформ с C++ и объектами. Незначительное снижение скорости и увеличение использования памяти (если таковое имеется) в тысячу раз окупается за счет повышения ремонтопригодности и удобства использования кода.

Подумайте о стоимости часа времени разработчика.

Подумайте о стоимости часа процессорного времени.

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

Я не читал эту книгу, но мне трудно поверить, что они написали книгу, «основу которой ... является то, что объектно-ориентированное программирование очень расточительно с точки зрения памяти» (полное раскрытие: Энди и Барбара - мои друзья).

Энди никогда бы не сказал, что ООП тратит впустую память. Он БЫЛ сказал, что конкретный алгоритм или метод является расточительным, и в некоторых случаях мог бы рекомендовать менее объектно-ориентированный подход, но он был бы первым, кто утверждал, что, как правило, объектно-ориентированные проекты не более или менее расточительны, чем любой другой стиль программирование.

Аргумент, что объектно-ориентированный дизайн расточителен, в значительной степени исходит из того факта, что EXE-файлы C++ программ "hello world" имеют тенденцию быть больше, чем EXE-файлы программ C "hello world". В основном это связано с тем, что iostreams больше printf (но тогда iostreams делает больше).

C++ и ООП сами по себе не являются неэффективными, но я видел, как многие программы на C++ выполняют операцию менее эффективно, чем эквивалентная программа на C. Самая большая проблема часто возникает из-за большого количества небольших выделений памяти, возникающих из-за новыйing отдельных объектов, а не маллокing целой группы из них одновременно. Точно так же полиморфизм и виртуальные функции прекрасны, но они несут накладные расходы, о которых не знают некоторые программисты на C++. Кусочное построение объектов также может быть намного медленнее, чем один грязный большой мемсет из вышеупомянутого массива структур маллокed.

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

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

Кроме того, ничто в C++ не делает его медленным, в отличие от других языков, любая медлительность - это чисто реализация библиотеки или разработка алгоритма.