Бьерн Страуструп: вокруг С++

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

Плохо это или хорошо, но с самого начала работы над C++ я выдерживал высокую степень совместимости с Си и комитет по стандартизации продолжил эту линию. Это довольно сильное ограничение: многое в С++ можно было бы с технической точки зрения сделать лучше, но в свете требования совместимости с Си это было нереалистично. Более того, дефекты Си при этом, по-существу, возводились в квадрат. Я считал принципиальным построить надлежащую систему типов, и выделил именно этот комплекс проблем, когда надо было выбирать, какие узкие места Си корректировать. И пока никто не убедил меня, что имелась альтернатива моему подходу - разве что построить еще один культовый язык, который выглядел бы безупречным в глазах небольшой группы приверженцев, - но я-то ориентировался на создание практического инструмента. Скажу больше: если бы в начале работы я решил, что Си - не тот язык, с которым новый язык должен быть совместим, то я бы выбрал на его роль какой-нибудь другой язык. И я по-прежнему убежден, что нет смысла начинать с нуля и заниматься изобретением велосипеда. Зачем предлагать еще один способ записи цикла?

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

Некоторое время тому назад меня попросили написать статью о С++ для Второй конференции ACM по истории языков программирования (они проводятся раз в 15 лет) и отметить в ней то, что я считаю своей самой большой ошибкой. Так вот, есть всего лишь один кандидат на этот титул: мне не удалось написать приемлемую базовую библиотеку с тем, чтобы включить ее в версию 1.0, выпущенную в 1985 г. В свое оправдание скажу, что я в то время просто не знал, как написать действительно хорошую библиотеку и нуждался в "образцах", чтобы обеспечить эффективные, гибкие контейнеры с безопасной типизацией. Результат этой ошибки - беспорядок (мягко говоря) из-за наличия несовместимых базовых библиотек, очень различающихся как по идеологии построения, так и по качеству.

К счастью, комитет по стандартизации смог прийти к соглашению о том, как должна выглядеть действительно адекватная базовая библиотека. Так что мы теперь имеем то, что я не смог сделать (и не знал как спроектировать и реализовать) десять лет назад. Большой вклад в работу по проектированию структуры контейнеров и базовых алгоритмов внес Алекс Степанов. И надо сказать, эти годы потрачены не зря: теперь библиотечные компоненты строятся на базе отработанных за это время принципов и методов.

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

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

Не думаю, что я вправе подсказывать сообществу Си, как им стандартизировать язык. Да и какой в этом смысл: те, кто мог бы оценить мои советы, в большинстве своем так или иначе уже программируют именно на С++. Комитет по стандартизации Си будет действовать так, как считает нужным, и наверняка лучше меня знает нужды своего сообщества. Однако программистское сообщество не нуждается еще в одном, несовместимом с уже имеющимися, диалекте Си. К тому же надо иметь в виду эффект инерционности. "Библия Си" [4] еще не устарела; нынешний ANSI C, несомненно, останется в силе и после обнародования нового стандарта - так же, как различные марки С++ будут неплохо сосуществовать и после приобретения стандартом С++ официального статуса. Без сомнения, новые особенности C9x неизбежно станут еще одним источником нестабильности в обоих (Си и С++) сообществах.

Очевидно, что синтаксис Java похож на синтаксис C++. Однако это все же фундаментально иной язык, поддерживающий отличную от С++ культуру и иные (на самом деле более ограниченные) стили программирования. Java определенно не похож и на тот C++, который я - мысленно - спроектировал бы в отсутствие налагаемых совместимостью с Си ограничений. От Java ждут очень многого, особенно в связи с интеграцией с Web, и эти ожидания подстегиваются дорогостоящими маркетинговыми акциями. Время покажет, будет ли Java дееспособен как универсальный язык. Хотелось бы посмотреть, как большинство программистов и менеджеров будут реагировать на "открытие" (для многих уже сейчас очевидное), что безопасность Java и в особенности JavaScript оставляет желать много лучшего. Часто путают безопасность типов языка программирования (что корректная реализация Java обеспечивает) с собственно безопасностью - поддержкой целостности системы и обеспечением конфиденциальности и секретности, что, по-видимому, может серьезно пострадать при использовании Java. Мои коллеги в AT&T, занимающиеся проблемами безопасности, в шутку называют Java "языком реализации вирусов". Если же вернуться к сравнению С++ и Java, то вспомним следующие фундаментальные характеристики С++: абстракция данных; поддержка объектно-ориентированного программирования (ООП); "обобщенные" (generic) классы.

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

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

Думаю, что еще далеко не все оценили по достоинству механизм шаблонов, полезный для различных форм специфицирования. Рассмотрим для примера один набросок, показывающий, как можно определить список так, что единая реализация разделяется всеми списками указателей:

// general list: template class list 
{ /* ... */ }; 
// specialization for lists of void*: template<> class list { /* ... */ }; 
// general list of pointers (implemented using list): 
template class list : list { /* ... */ }; 

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

Исходите из проблемы, которую нужно решить. Полезный язык - это решение хорошо понятого множества проблем, а не просто нечто, удовлетворяющее неким модным критериям того, как должен выглядеть язык программирования. Если вы не имеете действительно серьезной проблемы, которая не может быть решена с использованием любого из существующих языков, то даже и не думайте о проектировании еще одного языка. Помните, что проектирование языка - эта та сфера деятельности, где вероятность неудач составляет почти 100%. И никому не советую этим заниматься, если есть альтернатива. Сопротивляйтесь такой работе. Если же все-таки вы должны проектировать новый язык, то заимствуйте из уже известных языков столько, сколько сможете (не забывая выражать благодарность их авторам). И будьте готовы к неудаче и к очень большой работе - может быть, и преуспеете.

Язык С++ обеспечивает то, что обещал. Нельзя ожидать, что даже такой язык окажется способен покрыть все вдруг вошедшие в моду и сверх всякой меры рекламируемые при раскрутке какого-то другого языка особенности. С++ - это язык программирования, а не язык спецификации модулей или операционная система. Он, как и другие языки, не может обеспечить всем все. Вы можете строить "встраиваемые компоненты", используя С++, но это не то, для чего он в основном предназначен, а потому - требует усилий. Совместимость - тяжелая проблема. Не все понимают, что только через огромную работу по достижению соглашений между многими организациями, к тому же конкурирующими между собой, могла быть достигнута совместимость фрагментов программ на Си, подвергшихся компиляции с помощью различных компиляторов. Должно быть соглашение о последовательности вызова функций, форматах данных, деталях арифметики с плавающей точкой и т.д. С++ в этом отношении потяжелее, чем Си, но ненамного. Вообще, почти все тяжелые проблемы имеют не технический, а политический характер. Вопрос же множественного наследования стоит совершенно отдельно от любого вопроса, связанного с двоичными стандартами и совместимостью компиляторов С++. Я полагаю, что отсутствие MI (по крайней мере - в ранних версиях SOM) если о чем и говорит, так только о неравнодушии их авторов к Smalltalk и Objective C. В языках же, подобных С++, которые полагаются на статическую проверку типов интерфейсов, некоторая форма множественного наследования весьма существенна. Альтернатива - деформированный код, небезопасный интерфейс, или все это вместе.

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

Литература