Ранние эксперименты по интегрированию С++ и динамического связывания были настолько многообещающими, что я ожидал повсеместного распространения динамического связывания классов еще несколько лет назад. Например, еще в 1990 г. существовала работающая методика эффективного и безопасного инкре-мептного связывания, основанная на абстрактных типах [Stroustrup, 1987d], [Dor-ward, 1990]. В реальных системах она использовалась не очень пшроко, но абстрактные классы оказались важны для уменьшения числа повторных компиляций после изменения исходного кода и вообще для упрощения использования компонентов, полученных из разных источников (см. раздел 13.2.2).

Еще один важный вопрос, остающийся нерешенным, - поддержка эволюции программного обеспечения. Коль скоро библиотека выпушена в обращение, ее реализацию можно изменить только в том случае, если пользователи не зависят от таких деталей, как размер объекта, или могут и готовы перекомпилировать свой код с повой версией библиотеки. Объектные модели - 0LE2 от Microsoft, SOM от IBM и CORBA от Object Management Group - решают эту проблему путем предоставления интерфейса, скрывающего детали реализации и задуманного независимым от конкретного языка. Последнее вызывает у программиста на С++ некоторые неудобства и обычно сопровождается потерями программы скорости или памяти. Кроме того, у каждого из гигантов индустрии, похоже, есть свой собственный стандарт для решения описанной проблемы. Только время покажет, насколько эти методы помогают или мешают С++-программистам. Механизм пространств имен - подход к эволюции интерфейсов внутри самого С++ (см. раздел 17.4.4).

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

9.4.4. За пределами файлов и синтаксиса

Как я вижу среду для разработки программ на С++? Прежде всего - инкре-ментная компиляция. Если вносится небольшое изменение, то система понимает , что оно небольшое, и генерирует новую версию программы мгновенно. Моментальные ответы хотелось бы получать также на простые вопросы и указания типа: Показать объявление f , Какие еще f есть в области действия? , Как разрешен этот вызов оператора +? , Какие классы произведены от Shape? и Какие деструкторы вызываются в конце этого блока?

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

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

То, что в основе реализаций С++ лежат символьно-ориентированные инструменты, всегда было главны.м препятствием на пути развития языка. Если нужно препроцессировать и перекомпилировать каждый заголовочный файл, прямо или косвенно включенный в файл, где находится слегка измеиеиная функция, то для этого требовалось определенное, пусть и небольшое время. Существует несколько методов, позволяющих избежать ненужных переко.мпиляций, но, по-моему, наиболее перспективный и интересный подход - отказаться от традициоииого исходного текста и положить в основу инструментов абстрактное внутреннее представление. Ранний вариант такого представления можно найти в работах [Murray, 1992], [Koenig, 1992]. Естественно, текст все равно необходи.м - его вводят и читают пользователи, - но он легко преобразуется системой во внутреннюю форму и реконструируется по запросу. Фор.матирова1ше текста с соблюдешш.м некоторых правил отступа - лишь один из многих возможных взглядов на профа.мму. Простейшее применение этого замечания: текст програм.мы, который каждый из пользователей видит отфор.матированным в своем люби.мом стиле, а вы - в вашем.

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

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

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

9.4.5. Подведение итогов и перспективы

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

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

Ду.мается, что пока мы работали лишь с наименьшей частью возможностей языка C-I-+. Я предвижу, что в будущем центр деятельности и развития сместится от собстве1ию языка к инструментам, средам, библиотекам, приложениям и т.д., которые зависят от него и возводятся на его фундаменте.