Искусство программирования для Unix
Шрифт:
fetchmail совершает простейшие действия по управлению динамической памятью. Единственная сложная структура данных программы состоит из однонаправленного списка управляющих блоков, по одному на каждый почтовый сервер, который составляется только один раз при запуске и довольно незначительно изменяется впоследствии. Это значительно ослабляет довод против использования С, обходя основной недостаток языка.
С другой стороны, эти управляющие блоки достаточно сложны (они включают в себя строки, флаги и численные данные) и их трудно было бы обрабатывать как связанные объекты быстрого доступа на языке реализации без эквивалентной С функции структуры.
Наконец, fetchmail нуждается в возможности анализировать довольно сложный синтаксис спецификации для управляющей информации по каждому почтовому серверу. В Unix такая проблема классически решается с помощью генераторов С-кода, вырабатывающих исходный код для лексического и грамматического анализатора из декларативных спецификаций. Существование уасс и lex было доводом в пользу С.
fetchmail можно было бы на приемлемом уровне реализовать на Python, хотя и со значительной потерей производительности. Размер и сложность структуры данных fetchmail полностью исключили бы shell и Tel и строго указывали бы на недопустимость использования Perl. При этом предметная область программы находится за пределами естественных возможностей Emacs Lisp. Реализация на языке Java не была бы лишена смысла, но объектно-ориентированный стиль и уборка мусора дали бы небольшой выигрыш в специфических проблемах fetchmail по сравнению с теми, которые уже решались с помощью С. С++ так же не смог бы значительно упростить сравнительно простую внутреннюю логику fetchmail.
Однако реальная причина написания fetchmail на С состоит в том, что программа создавалась как постепенное развитие ее предшественника, уже написанного на С. Существующая реализация на С прошла обширное тестирование на разнообразных платформах, на необычных и специфических серверах. Повторная реализация на другом языке была бы сложной и запутанной. Более того, fetchmail зависит от импортируемого кода для функций (таких как NTLM-аутентификация), которые очевидно не доступны на более высоком уровне, чем С.
Интерактивный конфигуратор fetchmail, лишенный традиционной проблемы С, написан на Python; соответствующий учебный пример рассматривается далее.
14.4.2. С++
Когда в середине 1980-х годов С++ был впервые выпущен в свет, объектно-ориентированные языки программирования были широко разрекламированы как радикальное средство против сложности программного обеспечения. Объектно-ориентированные возможности С++ казались бесспорным преимуществом над С, и приверженцы ожидали, что С++ быстро сделает своего предшественника устаревшим.
Этого не случилось. Отчасти причинами могут быть проблемы в самом С++; требование обратной совместимости с С привело ко многим компромиссам в конструкции. Кроме всего прочего, данное требование помешало перевести С++ на полностью автоматическое управление динамической памятью и решить самую серьезную проблему С. Позже "гонка вооружений" между различными разработчиками компиляторов, которую не сдерживала слабая и преждевременная попытка стандартизации, привела к тому, что С++ стал "витиеватым" и чрезвычайно сложным языком.
Причиной послужило также и то, что самой
Возможно, что реализация ОО-технологии на С++ особенно склонна к созданию проблем. Существуют данные, которые говорят о том, что расходы на жизненный цикл программ на С++ больше, чем у эквивалентов, написанных на С, FORTRAN или Ada. Является ли данная проблема проблемой ОО, проблемой С++, или это комплексная проблема — пока не ясно, хотя есть смысл подозревать последнее [341.
В последние годы С++ включил в себя некоторые важные не-ОО-идеи. В языке существуют исключения, подобные исключениям в Lisp, т.е. можно добавлять объект или значение в стек вызовов до тех пор, пока его не перехватит обработчик. STL (Standard Template Library, стандартная библиотека шаблонов) обеспечивает типовое программирование, т.е. возможность писать код алгоритмов, независимых от сигнатур их данных, и компилировать их для выполнения необходимых функций во время выполнения. (Это необходимо только для языков, выполняющих статический контроль типов в процессе компиляции; более динамические языки просто передают ссылки на переменные без типа и поддерживают идентификацию типов во время выполнения.)
Эффективный компилируемый язык, совместимость снизу вверх с языком С, объектно-ориентированная платформа, связующий материал для самых современных методик, таких как STL и типовое программирование, — С++ претендует на роль универсального средства, но ценой этого является сложность, гораздо большая, чем та, с которой может справиться мозг отдельного программиста. Как было отмечено в главе 4, главный конструктор языка признал, что он и не ждет, что какой-либо один программист сможет постичь язык полностью. Unix-хакеры не слишком хорошо отреагировали на сложность С++. Подтверждением этого служит одно из анонимных, но известных определений: "С++ — это спрут, полученный путем пришивания лишних ног собаке".
Однако фундаментальная проблема заключается в том, что по существу С++ является просто еще одним традиционным языком. Он лучше сдерживает проблему управления памятью, чем до создания стандартной библиотеки шаблонов (STL), и значительно лучше, чем С. Однако это довольно сомнительное решение проблемы, и оно не будет надежно работать, если в коде не используются объекты и только объекты. Возможности ОО для многих типов приложений незначительны и просто добавляют сложности в С, не достигая весомых преимуществ. Доступны компиляторы С++ с открытым исходным кодом; если бы С++ определенно превосходил С, то в настоящее время он бы доминировал.
Подводя итоги, можно сделать вывод, что преимуществом С++ является сочетание эффективности компилируемого языка со средствами объектно-ориентированного и типового программирования. К недостаткам относятся его вычурность и сложность, а также склонность к поддержке сверхсложных конструкций.
Использование С++ целесообразно в том случае, когда существующий инструментарий или служебные библиотеки С++ предлагают значительные преимущества для приложения или когда предметная область приложения лежит в упомянутых выше областях, где использование ОО-языка, несомненно, является большим преимуществом.