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

Question

я книгу рекомендуется ставить под названием:

Accelerated C++ Практическое программирование на примере Эндрю Koenig и Барбара Э. Му Addison-Wesley, 2000 ISBN 0-201-70353 -Х

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

Я имею в виду, что большинство книг по программированию имеют одинаковую срок хранения молока, но если ваше кодирование клиент-серверного приложения (базы данных, сервера и всех) (а не драйвера устройства или видеоигры) действительно стоит неудобства для того, чтобы иметь незаменимый код только для ускорения скорости?

Или это стоит того, чтобы приложение запускалось на действительно старом компьютере клиента? Или иметь возможность запускать больше серверов на одном ящике?

Answer 1

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

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

Аргумент о том, что проекты ОО расточительны, в основном происходил из того факта, что EXE-программы C++ «hello world» имеют тенденцию быть более крупными, чем EXE-программы C «hello world». Это в основном потому, что iostreams больше printf (но тогда iostreams делает больше).

Answer 2

Wow, no.

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

Я бы сказал, что это несколько редуктивная сводка the book.

Одним словом, чтобы ответить на вопрос о названии, я буду продолжать рекомендовать как книгу, так и концепции, включенные в нее.

Я подозреваю, что совет больше связан с тем, что кто-то не должен создавать класс, чтобы реализовать алгоритм, который, я бы сказал, остается хорошим советом.

Answer 6

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

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