Б. Страуструп - Дизайн и Эволюция C++. 2006 (1160775), страница 53
Текст из файла (страница 53)
Чтобы преодолез ь такой барьер, было сделано следующее: ш С++ генерирует кол, который по быстродействию и расходу памяти может на равных конкурировать к признанным лидером в этой области — языком С. Любой язык, задачей которого является нс уступить или даже превзойти С, просто «обязан быть быстрым». Необходимую производительность С++ обеспечивает как для традиционно структурированного кода, так и для основанного на абстракциях данных и объектно-ориентированных методах; з такой код может интегрироваться с существующими программами и получаться на широко распространенных платформах.
Высокая степень переносимости считалась чрезвычайно важным критерием, как и способность сосуществовать с уже написанным кодом и с традиционными инструментами, например отладчиками и редакторами связей; ц в С++ допускается постепенный переход на новые приемы программирования. Благодаря С++ доступны каждому стали объектно-ориентированное программирование н абстракции данных. С++ также явился мощным стимулом для языков, поддерживающих в том или ином виде объектно-ориентированное программирование и абстрагирование данных. Появление С++ помогло и пользователям других языков, побудив разработчиков этих языков увеличивать производительность и гибкость.
9.2.2. Является ли С++ логически последовательным языком? В целом и я, и большинство пользователей довольны языком С++. Есть, конечно, много деталей, которые я улучшил бы, если бы мог. Однако фундаментальная концепция сильно типизированного языка, основанного на классах с виртуальными функциями и предоставляющего средства для низкоуровневого программирования, кажется мне здравой. Кроме того, все основные срепства тесно связаны и поддерживают друг друга. Оценка пройденного пути ~~ВИИИИИИИ 9.22.1.
Что можно и нужно было сделать по-другому? Какой язык справился бы с решением тех задач, для которых проектировался С++, лучше? Рассмотрим решения первого порядка (см. разделы 1.1, 2.3 и 2.7): а использование статического контроля типов и классов в духе Зппп!а; о четкое разделение между языком и средои; о совместимость с С на уровне исходных текстов (атак близко к С, насколько это возможноь); о совместимость с С на уровне редактирования связей и размещения объектов в памяти (чистинные локальные переменныск); о независимость от наличия сборщика мусора. Я по-прежнему считаю, что статический контроль типов является необходимым усчовием хорошего проектирования и эффективности выполнения. Если бы мне пришлось создавать новый язык для тех задач, которые сегодня решаются на С++, я снова взял бы за основу модель контроля типов из %пш!а, а ие из Бшайга!к или Е!зр.
Как я много раз повторял: «Если бы я хотел имитировать Бща1Иайг, то построил бы гораздо лучшую имитацию. Лучше Бшайса!к, чем Бшайсайс, нет. Если вам нужен БшайгаПс, им и пользуйтесь» 19ггоцзггцр, 19901. Одновременное наличие статического контроля типов и их динамической идентификации (например, в форме вызовов виртуальных функций) требует некоторых непростых компромиссов по сравнению с языками, где есть только статический или только динамический контроль типов. Модели статических и динамических типов пе могут быть идентичны, поэтому всегда будет существовать некоторая сложность и отсутствие изящества, которых можно было бы избежать, если придерживаться какой-то одной модели. Однако мне не хотелось бы писать удовлетворяющие этому условию программы, Я также считаю существенно важным разделение языка и среды и не желаю пользоваться только одним языком, единственным набором инструментальных средств и одной операционной системой.
Чтобы иметь выбор, необходимо разделение. Однако если оно есть, то можно предоставить разные среды под разные требования к степени поддержки, потреблению ресурсов и переносимости. Однако недостаточно сделать что-то новое, надо еще, чтобы люди смогли перейти к этому новому от старых инструментов и представлений. Если бы не было С, то я бы сделал С++ совместимым с каким-то другим языком. Будучи основан на С, С++ унаследовал некоторые синтаксические несуразицы, путаные правила преобразования для встроенных типов и т.д.
Эти несовершенства были источником постоянных трудностей, но альтернатива — серьезная несовместимость между С и построенным на его базе языком или попытка внедрить язык, спроектированный с нуля, — принесла бы проблемы гораздо более серьезные, чем имеющиеся сейчас. В частности, совместимость с С на уровне компоновки и библиотек считалась абсолютно необходимой. Совместимость на уровне компоновки означала также и возможность связывания с программами на других языках, поскольку они могут быть связаны с кодом на С. ИЙИИИИИ11 Перспективы развития языка С++ Должен ли язык предоставлять ссылочную семантику для переменных (это означает, что имя является указателем на обьект, размещенный в другом месте), как в 8ша1!га1!«и Моби!а-З, или лучше иметь истинные переменные, как в языках С и Рааса!? Вопрос решающий и тесно связанный еще с несколькими; сосуществование с другими языками, эффективность во время исполнения, управление памятью, использование полиморфных типов.
В языке 8!шц!а есть ссылки на объекты классов и истинные переменные встроенных типов (и только). Я считаю открытым вопрос о том, можно ли спроектировать язык, сочетающий положительные стороны ссылок и истинных локальных переменных, сохранив определенную стройность, непротиворечивость. Между изяществом языка и преимуществами, которые дают ссылки и истинные переменные я предпочту иметь последние. Должен ли новый язык напрямую поддерживать сборку мусора, как, скажем, Мог[в!а-3? Если да, то удалось бы достичь основных целей С++, если бы в нем был сборщик мусора? В качестве необязательной возможности сборщик мусора желателен. Но он может негативно повлиять на быстродействие программы, время реакции и простоту переноса. Поэтому необходимость платить за сборку мусора всегда и везде — вряд ли правильный ход.
В С++ допускается наличие необязательного сборщика мусора [2пс[, с. 466-468!. Ведутся экспериментальные работы по реализации таких компиляторов С++. 9.2.2.2. От чего стоило бы отказаться? Еще в работе [8ггопзггцр, 1980! высказывалось опасение, что язык С вч!и С1аззез может оказаться слишком громоздким. Среди всех высказанных претензий пожелание иметь «язык поменьше» стоит на первом месте, и все же пользователи забрасывают меня и комитет по стандартизации предложениями о расширениях. Я не вижу, от какой составляющей С++ можно было бы отказаться, не жертвуя при этом поддержкой той или иной важной сферы применения.
Даже если полностью игнорировать вопросы совместимости, удастся упростить лишь немногие из фундаментальных механизмов С++. В основном это коснулось бы С-подмножества, но мы как-то забываем, что сам С вЂ” довольно большой и сложный язык. С++ он поддерживает несколько способов написания программ, несколько парадигм программирования. Поэтому-то он так велик.
В каком-то смысле С++— зто три языка в одном: а С-подобный язык (для поддержки низкоуровневого программирования); о Апа-подобный язык (для поддержки абстрактных типов данных); а Бппц1а-подобный язык (для поддержки объектно-ориентированного программирования); а прослойка, необходимая для интеграции всех этих средств в олин логически последовательный язык. Писать программы в любом из этих стилей можно и на С, но он не предоставляет прямой поддержки ни для абстрагирования данных, ни для объектно-ориентированного программирования, тогда как С++ непосредственно поддерживает несколько альтернативных подходов. Оценка пройденного пути 1ИЮИИИЕБ При создании программы всегда есть некоторое количество вариантов, но в большинстве языков выбор сделал за вас проектировщик языка. В случае С++ это не так — выбор за вами.
Такая гибкость, естественно, непереносима для тех, кто считает, что существует лишь один правильный способ действий. Она может также отпугнуть начинающих пользователей и преподавателей, полагаюц[их, что язык хорош, если его можно полностью освоить за неделю. С++ к таким языкам не относится. Он был спроектирован как набор инструментов для профессионалов, и жаловаться на то, что в нем слишком много возможностей, — значит уподобляться дилетанту, который, заглянув в чемоданчик обойщика, восклицает, что столько разных молоточков никому не потребуется.
Каждый язык, используемый для решения нетривиальных задач, развивается, чтобы полнее удовлетворить потребности пользователей. Это неизбежно ведет к усложнению. С++ здесь ие исключение, сложность языка увеличивается по мере усложнения задач, которые он призван решать. Если она не проявляется в самом языке, значит, присутствует в библиотеках и инструментальных средствах. Примеры языков, которые значительно «выросли» по сравнению с оригинальным проектом, — Лг(а, Е11(е), 1ззр (С1.05) и 5ша11га1к.
Из-за акцента С++ на статическом контроле типов усложнение в основном приняло форму расширений языка. Я сделал возможным поэтапное изучение и использование языка (см. раздел 7.2), чтобы он не воспринимался таким громоздким. Типичное для больших языков снижение производительности также минимизировано путем исключения излишних затрат (см. раздел 4.5). 9.2.2З. Что стоило бы добавить? В целом добавлять хотелось бы как можно лтеньше. В письме рабочей группы по расширениям в составе комитета по стандартизации С++ эта позиция изложена так: «Во-первых, мы попытаемся убедить вос не вносить новые предложения о расширении языка.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
