Б. Страуструп - Дизайн и Эволюция C++. 2006 (1160775), страница 34
Текст из файла (страница 34)
Возникает вопрос «Насколько близки должны быть определения Низкоуровневое программирование 11ИИИИИИШ С++ и С?» Как уже говорилось, С++ не претендует на стопроцентную совместимость с С, так как зто противоречило бы таким целям языка, как безопасное использование типов и поддержка проектирования. Но любых несовместимостей, не вступающих в конфликт с этими целями, мы избегали.
В большинстве случаев мы шлн на несовместимость с С, только если действующее в С правило оставляло «зияющую дыру» в системе контроля типов. С годами выяснилось, что совместимость с С вЂ” одновременно самый большой плюс и самый существенный минус С++. И это неудивительно.
Степень совместимости с С останется важнейшим вопросом и в будущем. Со временем совместимость будет становиться все меньшим преимуществом и все большей обузой. В связи с этим следует наметить путь решения вопроса (см. главу 9). Пе оставлять места языкам более низкого уровня, чвм С++, исключая ассемблер. Раз высокоуровневый язык должен полностью изолировать программиста от особенностей определенного компьютера, то задача системного программирования должна решаться с помощью какого-нибудь другого языка. Обычно таким языком был С.
Но потом С заменил языки высокого уровня в тех областях, где гибкость управления или скорость имели решающее значение. При этом система могла полностью переписываться на С, или для ее поддержки требовался человек, одинаково хорошо владеющий двумя языками. В последнем случае программист оказывался перед трудным выбором: какой язык предпочесть для ревгения конкретной задачи. Приходилось держать в уме примитивы и принципы обоих языков. В С++ предоставляются как низкоуровневые средства, так и механизмы абстракции, и поддерживается создание гибридных систем, где используется то и другое. Чтобы остаться жизнеспособным языком для системного программирования, в С++ должны быть заложены возможности напрямую работать с аппаратурой, контролировать размещение структур данных в памяти и иметь примитивные операции и типы данных, отображаемые непосредственно на аппаратные средства.
Если этого не будет, то придется использовать С или ассемблер. Задача проектирования языка состоит в изолировании низкоуровневых средств, чтобы прибегать к ним имело смысл лишь тогда, когда есть необходимость в прямом доступе к аппаратуре и операционной системе. Цель — защитить программиста от случайного неправильного использования, не возводя ненужных препятствий. Правило нулевых издержек: чвм не пользуетесь, за то ие платите. Обычно сложные языки заслуженно порицают за генерирование большого и медленного кода. Зачастую затраты, необходимые для поддержки развитых возможностей, распространяются и на все остальные. Например, в каждом объекте хранится служебная информация; косвенный доступ к данным выполняется всегда и везде, хотя реально необходим только в некоторых случаях; управляющие конструкции чрезмерно усложнены, чтобы поддержать «развитые абстракции управления».
Такая модель была признана неприемлемой для С++. Неоднократно при принятии тех или иных проектных решений обнаруживалось, что правилу нулевых издержек очень трудно следовать. Виртуальные функции (см. раздел 3.5), множественное наследование (см. раздел 12.4.2), идентификация типов во время выполнения (см. раздел 14.2.2.2), обработка исключений НИИИИИИИВ Правила проектирования языка С++ и шаблоны — в каждом случае средство принималось лишь после того, как я убеждался, что его можно реализовать с нулевыми издержками. Естественно, разработчик может согласиться на компромисс между данным правилом и другим полезным свойством системы, но подходить к этому надо с большой осторожностью, тем более что многие программисты резко и эмоционально реагируют на излишние затраты.
Пожалуй, именно данное правило заставило отказаться от включения в язык многих возможностей. Если есть сомнения, предоставлять средства для ручного контроля. Я не очень доверяю впередовой технологии» и не склонен думать, что нечто изощренное может быть доступным повсеместно. Хорошее подтверждение этому — встраиваемые функции (см. раздел 2А.1). Другой пример — инстанцирование шаблонов, где мне следовало быть осторожнее, тогда не пришлось бы потом добавлять механизм для явного контроля (см. раздел 15.10).
Управляемое распределение памяти — это пример ситуации, где за счет ручного управления удалось добиться важных преимуШеств, но только время покажет, не пострадали ли при этом автоматизированные механизмы (см. раздел 10.7). 4.6. Заключительное слово Совокупность всех вышеприведенных правил можно считать важнейшей особенностью языка.
Убери хоть одно — и, скорее всего, нарушится равновесие, что ударит по интересам какой-то группы пользователей. И то же самое произойдет, если любая из установок будет доминировать над остальными. Я старался, чтобы мои правила выглядели как утверждения и рекомендации, а не как набор запретов. При таком подходе становится гораздо труднее игнорировать новые идеи. В то же время мой взгляд на С++ как на язык для создания программного обеспечения с акцентом на средства, облегчающие структурирование программ, препятствует тенденции к внесению мелких изменений. Более подробный перечень вопросов, на которые надо ответить, рассматривая новое языковое средство, приведен в контрольном списке, предложенном рабочей группой по расширениям языка при комитете А1чБ1/150 (см. раздел 6А.1).
Глава Б. Хренелегии 1985-1993 гг. Не забывай: но все нужно време. Пнет Хойн 5.1. Введение В части П описываются все языковые средства, добавленные в С++. В данной же главе приводится последовательность событий. Причина, по которой хронология выделена в отдельный раздел, состоит в том, что фактическое время события не очень важно для окончательного определения С++. В общих чертах я знал направление, в котором идет развитие языка, проблемы, требующие решения, и необходимые для этого средства. Но не мог же я осуществить все задуманное в рамках одной крупной ревизии языка. Зто заняло бы слишком много времени и оставило бы меня без необходимой обратной связи с пользователями.
Поэтому расширения добавлялись к языку постепенно. Фактический порядок был чрезвычайно важен для тогдашних пользователей и существенен для поддержания логической стройности языка Однако для окончательной формы С++ он не играл такой уж значительной роли. Поэтому хронологически последовательное описание всех расширений лишь затемнило бы логическую структуру языка. Данная глава посвящена работе, которая привела к созданию версии С1гопс 2.0, написанию книги «ТЬе Аппогагед С++ Ке1егепсе Манна!» («Аннотированное справочное руководство по С«»») и усилиям по стандартизации. 1986 — 1989 гг. Версия 2.0 добавила к С++ такие возможности, как абстрактные классы, типобезопасную комйоновку и множественное наследование.
1988 — 1990 гг. В книге «ТЬе Аппоеагед С++ Ке1егепсе Манна!» описаны шаблоны и обработка исключений. Тем самым брошен серьезный вызов разработчикам компиляторов и открыт путь к революционным изменениям в способах программирования на С++. 1989-1993 гг. В результате усилий по стандартизации добавлены пространства имен, идентификация типов во время исполнения и многие менее важные средства для программиста на С++.
Во всех трех случаях была проделана большая работа по уточнению определения языка и его упорядочиванию. С моей точки зрения, все представляло собой одно действие, растянувшееся на длительный срок. БИИИИИИВ 5.2. Версия 2.0 Хронология 1985-1993 гг. ' 1151 образовалась как отделение АТЛЕТ, заиимаюшееся технической поддержкой и дистрибуцией 1Лх!Х и соответствующих инструментальных средств. Позже она выделилась в отдельную компанию под названием 11Ы1Х буиеш 1аЪогасопея а затем была куплена 1соте1 Ъ К середине 1986 г, абсолютно всем стало понятно направление развития С+».
Основные проектные решения были приняты. Следующим этшюм развития было внедрение параметризованных типов, множественного наследования и обработки исключений. Требовалось провести много экспериментов и на основе их результатов откорректировать курс, но даже это уже не могло кардинально изменить ситуацию.
С++ и раньше-то не отличался эластичностью, а теперь все возможности для радикальных изменений были исчерпаны. Оставалось, однако, много непростой работы. К этому времени во всем мире языком С++ пользовались примерно 2 тыс. человек. Согласно плану, выработанному Стивом Джонсоном и мной, повседневная работа над инструментарием (главным образом, С1гоп1) должна была перейти в ведение организации по разработке и технической поддержке. Это позволило бы мне сосредоточиться на новых возможностях и библиотеках. Предполагалось, что сначала АТЛЕТ, а затем и другие компании начнут создавать компиляторы и инструментальные средства, которые, в конце концов, сделают С1гопг ненужным. Фактически этот процесс уже начался, но хороший план пошел кувырком изза нерешительного и неумелого руководства разработкой. Проект разработки нового компилятора С++ отвлек внимание и ресурсы от задач сопровождения и развития С1гопс Планы начать поставку версии 1.3 в начале 1988 г.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
