9.2.2.1. Что можно и нужно было сделать по-другому?

Какой язык справился бы с решением тех задач, для которых проектировался С++, лучше? Рассмотрим решения первого порядка (см. разделы 1.1, 2.3 и 2.7):

□ использование статического контроля типов и классов в духе Simula;

□ четкое разделение между языко.м и средой;

□ совмести.мость с С на уровне исходных текстов ( так близко к С, насколько это возможно );

□ совместимость с С на уровне редактирования связей и размещения объектов в памяти ( истинные локальные переменные );

□ независимость от наличия сборщика мусора.

Я по-прежнему считаю, что статический контроль типов является необходимым условием хорошего проектирования и эффективности выполнения. Если бы мне пришлось создавать новый язык для тех задач, которые сегодня решаются на C++, я снова взял бы за основу модель контроля типов из Simula, а не из Smalltalk или Lisp. Как я много раз повторял: Если бы я хотел и.митировать Smalltalk, то построил бы гораздо лучшую имитацию. Лучше Smalltalk, чем Smalltalk, нет. Если вам нужен Smalltalk, им и пользуйтесь [Stroustrup, 1990]. Одновре.менное наличие статического контроля типов и их дина.мической идентификации (например, в форме вызовов виртуальных функций) требует некоторых непростых компромиссов по сравнению с языками, где есть только статический или только динамический контроль типов. Модели статических и динамических типов не могут быть идентичны, поэтому всегда будет существовать некоторая сложность и отсутствие изящества, которых можно было бы избежать, если придерживаться какой-то одной модели. Однако мне не хотелось бы писать удовлетворяющие этому условию профаммы.

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

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

Должен ли язык предоставлять ссылочную семантику для переменных (это означает, что имя является указателем на объект, размещенный в другом месте), как в Smalltalk и Modula-3, или лучше иметь истинные переменные, как в языках С и Pascal? Вопрос решающий и тесно связанный еще с несколькими: сосуществование с другими языками, эффективность во время исполнения, управление памятью, использование полиморфных типов. В языке Simula есть ссылки на объекты классов и истирпгые переменные встроенных типов (и только). Я считаю открытым вопрос о том, можно ли спроектировать язык, сочетающий положительные стороны ссылок и истинных локальных переменных, сохранив определенную стройность, непротиворечивость. Между изяществом языка и преи.муществами, которые дают ссылки и истинные переменные я предпочту иметь последние.

Должен ли новый язык напрямую поддерживать сборку мусора, как, скажем, Modula-3? Если да, то удалось бы достичь основных целей С++, если бы в нем был сборщик мусора? В качестве необязательной возможности сборщик мусора желателен. Но он может негативно повлиять на быстродействие программы, время реакции и простоту переноса. Поэтому необходимость платить за сборку мусора всегда и везде - вряд ли правильный ход. В С++ допускается наличие необязательного сборщика мусора [2nd, с. 466-468]. Ведутся экспериментальные работы по ре-а/п1зации таких компиляторов С++.

9.2.2.2. От чего стоило бы отказаться?

Еще в работе [Stroustrup, 1980] высказывалось опасение, что язык С with Classes может оказаться слишком громоздким. Среди всех высказанных претензий пожелание иметь язык поменьше стоит на первом месте, и все же пользователи забрасывают меня и комитет по стандартизации предложениями о расширениях. Я не вижу, от какой составляющей С++ можно было бы отказаться, не жертвуя при этом поддержкой той или иной важной сферы при.менения. Даже если полностью игнорировать вопросы совместимости, удастся упростить лишь немногие из фундаментальных механизмов С++. В основном это коснулось бы С-подмно-жества, но мы как-то забываем, что сам С - довольно большой и сложный язык.

С++ он поддерживает несколько способов написания программ, несколько парадигм программирования. Поэтому-то он так велик. В каком-то смысле С++ -это три языка в одно.м:

□ С-подобный язык (для поддержки низкоуровневого программирования);

□ Ada-подобный язык (для поддержки абстрактных типов данных);

□ Simula-подобный язык (для поддержки объектно-ориентированного программирования);

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

Писать программы в любом из этих стилей можно и на С, но он не предоставляет прямой поддержки ни для абстрагирования данных, ни для объектно-ориентированного программирования, тогда как С++ непосредственно поддерживает несколько альтернативных подходов.

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

Каждый язык, используемый для решения нетривиальных задач, развивается, чтобы полнее удовлетворить потребности пользователей. Это неизбежно ведет к усложнению. С++ здесь не исключение, сложность языка увеличивается по мере усложнения задач, которые он призван репшть. Если она не проявляется в са.мом языке, значит, присутствует в библиотеках и инстру.ментальных средствах. Примеры языков, которые значительно выросли по сравнению с оригинальным проектом, - Ada Eiffel, Lisp (CLOS) и Smalltalk. Из-за акцента С++ на статическом контроле типов усложнение в основном приршло форму расширений языка.

Я сделал возможным поэтапное изучение и использование языка (см. раздел 7.2), чтобы он не воспринимался таки.м фомоздким. Типичное для больших языков снижение производительности также минимизировано путем исключения излишних затрат (см. раздел 4.5).

9.2.2.3. Что стоило бы добавить?

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

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

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

И все же, что можно было бы добавить в С++ с учетом вышесказанного? Лично мне тех средств, которые описаны на страницах данной книги (включая и часть II, где говорится о шаблонах, исключениях, пространствах имен и идентификации типов во время исполн.ения), достаточно. Я хотел бы включить необязательную сборку мусора, но отношу это, скорее, к качеству компилятора, а не к средствам языка.

9.2.3. Основная недоработка языка

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