Концепции в Ускоренном C++ Практическом Программировании на Примере до сих пор остаются в силе?
Мне порекомендовали книгу под названием:
Ускоренное практическое программирование на C++ на примере Эндрю Кенига и Барбары Э. Му, Аддисон-Уэсли, 2000 ISBN 0-201-70353-X
Основой этой книги является то, что объектно-ориентированное программирование очень расточительно с точки зрения памяти, и что большая часть исходного кода не должна быть написана таким образом, вместо этого вы должны использовать все вызовы встроенных функций и процедурное программирование.
Я имею в виду, я знаю, что большинство книг по программированию имеют примерно такой же срок годности, что и молоко, но если вы кодируете клиент-серверное приложение (базу данных, сервер и все) (не драйвер устройства или видеоигру), это действительно стоит того, чтобы иметь необслуживаемый код только для повышения скорости?
Или стоит просто запустить приложение на действительно старой машине клиента? Или чтобы иметь возможность запускать больше серверов на одном компьютере?
6 ответов
Я не читал эту книгу, но мне трудно поверить, что они написали книгу, "основа которой состоит в том, что объектно-ориентированное программирование очень расточительно с точки зрения памяти" (полное раскрытие: Энди и Барбара мои друзья).
Энди никогда бы не сказал, что ООП тратит память. Он сказал бы, что конкретный алгоритм или метод является бесполезным, и в некоторых случаях он может рекомендовать менее ОО-подход, но он будет первым, кто будет утверждать, что по общему правилу ОО-проекты не более или менее расточительны, чем любой другой стиль программирование.
Аргумент о том, что ОО-проекты расточительны, во многом объясняется тем фактом, что EXE-файлы C++-программ "hello world" имеют тенденцию быть больше, чем EXE-файлы C-программ "hello world". Это в основном потому, что iostreams больше, чем printf (но тогда iostreams делает больше).
Вау, нет
Современные компиляторы C++ превосходны. Массовое использование памяти - это скорее признак плохого дизайна или большого объема данных в памяти. Затраты, необходимые для классов C++, минимальны и в настоящее время не являются проблемой.
Объектно-ориентированное программирование - это способ написания компонентов таким образом, что они могут логически группировать действия, связанные с одной концепцией (т. Е. Все действия для "машины" или все действия для "кошки"). Это не значит, что нельзя писать объекты спагетти неправильно, но, как говорится, вы можете писать на языке COBOL на любом языке.
В качестве еще одного примера, в наши дни вполне возможно и принято писать для встроенных программных платформ с C++ и объектами. Незначительное снижение скорости и увеличение использования памяти (если есть) окупается в тысячу раз за счет повышения удобства обслуживания и удобства использования кода.
C++ и OOP не являются неэффективными сами по себе, но я видел, что многие программы на C++ выполняют операции менее эффективно, чем эквивалентные программы на C. Самым большим виновником часто является большое количество небольших выделений памяти, возникающих из-за новых отдельных объектов, а не из-за того, что они искажаются сразу. Точно так же полиморфизм и виртуальные функции великолепны, но они несут накладные расходы, о которых некоторые программисты C++ не знают. Кусочное построение объектов также может быть намного медленнее, чем один грязный большой набор вышеупомянутых неправильно распределенных массивов структур.
Я предполагаю, что для большинства приложений на современных компьютерах это не является проблемой. Учитывая, что C++ также включает в себя все C как подмножество, ничто не мешает вам смешивать и сопоставлять парадигмы, как того требуют ситуации. Более новые обработчики кучи также намного лучше, чем ранние попытки MS, и помогают bg.
Основой этой книги является то, что объектно-ориентированное программирование очень расточительно с точки зрения памяти, и что большая часть исходного кода не должна быть написана таким образом, вместо этого вы должны использовать все вызовы встроенных функций и процедурное программирование.
Я бы сказал, что это несколько упрощенное резюме книги.
Короче говоря, чтобы ответить на заглавный вопрос, я бы по-прежнему рекомендовал и книгу, и концепции, включенные в нее.
Я подозреваю, что совет больше похож на тот, что кто-то не должен создавать класс просто для реализации алгоритма, что, я бы сказал, остается хорошим советом.
Подумайте о стоимости часа времени разработчика.
Подумайте о стоимости часа процессорного времени.
И, как говорится, потеря производительности при кодировании объектно-ориентированной абсолютно пренебрежимо. Особенно учитывая, что когда ваша программа вычисляет, она вычисляет что-то - и это, вероятно, гораздо больше зависит от природы используемого алгоритма, чем от того, используется ли ООП или нет.
Некоторые из ответов полностью упускают суть. ООП в C++ имеет много возможностей быть намного быстрее, чем их аналоги в Си. Я приведу пример из "Эффективного C++" Скотта Мейерса: "Быстрая сортировка выполняется медленнее, чем сортировка C++, потому что компилятор может легко встроить вызов функции в C++, тогда как он не может сделать это в C из-за быстрой сортировки". передал указатель на функцию.
Кроме того, ничто в C++ не делает его медленным, в отличие от других языков, любая медлительность - это чисто реализация библиотек или разработка алгоритмов.