С++ и С? Как уже говорилось, С++ не претендует на стопроцентную совместимость с С, так как это противоречило бы таким целям языка, как безопасное использование типов и поддержка проектирования. Но любых несовместимостей, не вступающих в конфликт с этими целями, мы избегали. В большинстве случаев .мы шли на несовместимость с С, только если действующее в С правило оставляло зияющую дыру в системе контроля типов.

С годами выяснилось, что совместимость с С - одновременно самый большой плюс и са.мый существенный .минус С++. И это неудивительно. Степень сов.мес-ТИ.МОСТИ с С останется важнейшим вопросом и в будущем. Со вре.мене.м совместимость будет становиться все меньшим преимуществом и все большей обузой. В связи с этим следует наметить путь решения вопроса (см. главу 9).

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

Чтобы остаться жизнеспособным языком для системного программирования, в C++ должны быть заложены возможности напрямую работать с аппаратурой, контролировать размещение структур данных в памяти и и.меть примитивные операции и типы данных, отображаемые непосредственно на аппаратные средства. Если этого не будет, то придется использовать С или ассемблер. Задача проектирования языка состоит в изолировании низкоуровневых средств, чтобы прибегать к НИ.М имело смысл лишь тогда, когда есть необходимость в прямом доступе к аппаратуре и операционной системе. Цель - защитить програ.ммиста от случайного неправильного использования, не возводя ненужных препятствий.

Правило нулевых издержек: чем не пользуетесь, за то не платите. Обычно сложные языки заслуженно порицают за генерирование большого и медленного кода. Зачастую затраты, необходимые для поддержки развитых возможностей, распространяются и на все остальные. Напри.мер, в каждом объекте хранится служебная информация; косвенный доступ к данным выполняется всегда и везде, хотя реально необходим только в некоторых слзаях; управляющие конструкции чрезмерно усложнены, чтобы поддержать развитые абстракции управления . Такая модель была признана неприемлемой для С++.

Неоднократно при принятии тех или иных проектных решений обнаруживалось, что правилу нулевых издержек очень трудно следовать. Виртуальные функции (см. раздел 3.5), множественное наследование (см. раздел 12.4.2), идентификация типов во время выполнения (см. раздел 14.2.2.2), обработка исключений

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

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

Если есть сомнения, предоставлять средства для ручного контроля. Я не очень доверяю передовой технологии и не склонен думать, что нечто изощренное может быть доступным повсеместно. Хорошее подтверждение этому - встраиваемые функции (см. раздел 2.4.1). Другой пример - инстанцирование шаблонов, где мне следовало быть осторожнее, тогда не пришлось бы потом добавлять механизм для явного контроля (см. раздел 15.10). Управляемое распределение памяти - это пример ситуации, где за счет ручного управления удалось добиться важных преимуществ, но только время покажет, не пострадали ли при этом автоматизированные механизмы (см. раздел 10.7).

4.6. Заключительное слово

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

Я старался, чтобы мои правила выглядели как утверждения и рекомендации, а не как набор запретов. При таком подходе становится гораздо труднее игнорировать новые идеи. В то же время мой взгляд на С++ как на язык для создания программного обеспечения с акцентом на средства, облегчающие структурирование программ, препятствует тенденции к внесению мелких изменений.

Более подробный перечень вопросов, на которые надо ответить, рассматривая новое языковое средство, приведен в контрольном списке, предложенном рабочей группой по расширениям языка при комитете ANSI/ISO (см. раздел 6.4.1).

Глава 5. Хронология 1985-1993 гг.

Не забывай: на все нужно время.

ПиетХайн

5.1. Введение

в части II описываются все языковые средства, добавленные в С++. В данной же главе приводится последовательность событий.

Причина, по которой хронология выделена в отдельный раздел, состоит в том, что фактическое время события не очень важно для окончательного определения С++. В общих чертах я знал направление, в котором идет развитие языка, проблемы, требующие решения, и необходимые для этого средства. Но не мог же я осуществить все задуманное в рамках одной крупной ревизии языка. Это заняло бы слишком много вре.мени и оставило бы меня без необходи.мой обратной связи с пользователями. Поэтому расширения добавлялись к языку постепенно. Фактический порядок был чрезвычайно важен для тогдашних пользователей и существенен для поддержания логической стройности языка. Однако для окончательной формы С++ он не играл такой уж значительной роли. Поэтому хронологически последовательное описание всех расширений лишь затемнило бы логическую структуру языка.

Данная глава посвящена работе, которая привела к созданию версии Cfront 2.0, написанию книги The Annotated С++ Reference Manuals ( Аннотированное справочное руководство по С++ ) и усилиям по стандартизации.

1986-1989 гг. Версия 2.0 добавила к С++ такие возможности, как абстрактные классы, типобезопасную комйоновку и множественное наследование.

1988-1990 гг. В книге ТЬе Annotated С++ Reference Manuab описаны шаблоны и обработка исключений. Тем са.мым брошен серьезный вызов разработчикам компиляторов и открыт путь к революционным изменениям в способах программирования на С++.

1989-1993 гг. В результате усилий по стандартизации добавлены пространства имен, идентификация типов во время исполнения и многие менее важные средства для программиста на С++.

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