Редкая профессия

выполнили вашу первую программу на Си++!'?—?недопустимая профанация предмета.

С тех пор мы считаем, что настоящее пособие по сложному современному языку программирования общего назначения (уровня Си++ или Ada95) должно иметь форму, близкую упоминавшейся выше книге Эллис и Страуструпа,-- комментированный стандарт. Только такая книга может дать читателю настоящее понимание языка. Да, читать и пытаться понять строгий, сложно построенный, местами даже занудный текст будет весьма непросто?—?но кто сказал, что профессия программиста проста? Мы обязательно сделаем такую книгу по Си++, когда его Стандарт, наконец, будет принят.

Стандарт принят в 1998 году?—?уже почти три года назад, а обещанных комментариев до сих пор нет… Собственно текст Стандарта я практически полностью перевел, надо бы засесть и за комментарии. Однако одному мне не справиться… Саша Кротов, где ты!?..

Комментарий 2001 года

Мы подошли к делу серьезно. Три или четыре месяца мы практически не программировали. Мы изучали Эллис и Страуструпа ('Зеленую книгу') вдоль и поперек и во всех мыслимых направлениях, продумывали общую конфигурацию компилятора, выбирали построение основных структур данных и важнейших алгоритмов, предлагали и обсуждали проектные и технические решения и писали проект.

Прекрасно помню чувство гордости, которое мы испытали, увидев наглядное свидетельство наших трудов?—?увесистый том, привезенный Вальтером, красиво отформатированный, распечатанный на лазерном принтере (у нас их тогда и в помине не было) и даже, кажется, переплетенный. Сейчас, когда прошло уже около трех лет, очень многие наши проектные решения кажутся прямолинейными, наивными и даже неверными; некоторые пришлось менять уже в процессе реализации, но, тем не менее, проект дал необходимую основу для работы.

Этот текст, кажется, произвел достаточное впечатление на бельгийцев; они вполне убедились в уровне нашей квалификации. Тогда показалось удивительным, но некоторых простых вещей они просто не знали: например, что typedef-объявление не вводит новый тип, конструкции extern 'С' могут быть вложенными и т.д. Не говоря уже о более специфических аспектах. Когда мы описывали в проекте технику компиляции вызовов, мы употребили термин 'thunk' (короткий код для вычисления фактического параметра). Оказывается, они, сделавшие несколько коммерческих компиляторов, не знали, что это такое! С удовольствием и тайным злорадством я выписал из классической книги Гриса[2] и послал им большую цитату, объясняющую этот термин…

Первые радости

Начнем с синтаксиса (самого, казалось бы, простого аспекта, однако борьбой с ним завершаются попытки очень многих). Несколько первых впечатлений. Во-первых, язык просто очень большой. Это означает, что синтаксические таблицы?—?составленные вручную или построенные каким-нибудь генератором распознавателей, вроде YACC, будут довольно велики, что, естественно, замедлит скорость синтаксического разбора.

Однако при внимательном анализе оказывается, что в языке имеется сравнительно большое число «микро»-регулярностей?—?часто повторяющихся устойчивых последовательностей лексем. Например, пары пустых скобки: (), [] , пустой список параметров (void), завершитель списка параметров ...) встречаются очень часто. После служебных слов if, switch, while всегда должна стоять левая круглая скобка, после break и continue?—?точка с запятой, а после слова goto располагаются идентификатор и точка с запятой. Таких регулярностей набирается несколько десятков, так что если рассматривать их как отдельные лексемы, объем синтаксиса заметно сокращается. Введение каждой такой 'суперлексемы' экономит по крайней мере одно обращение синтаксического анализатора к таблице разбора. Усложнение распознавателя лексем (сканера), вынужденного составлять суперлексемы из пар или троек обычных лексем, при этом получается весьма незначительное; более того, если сканер во время одного вызова распознает, например, не только служебное слово switch, но и левую круглую скобку, идущую за ним, получится экономия и на числе обращений к сканеру!

Во-вторых, в синтаксисе есть неоднозначности. Это надо оценить: в Стандарте (!) языка программирования прямо написано, что некоторые конструкции можно трактовать двояко?—?либо как объявление, либо как оператор! В несколько упрощенном виде формулировка из стандарта выглядит так: 'выражение, содержащее в качестве своего самого левого подвыражения явное преобразование типа, которое записано в функциональном стиле, может быть неотличимо от объявления, в котором первый декларатор начинается с левой круглой скобки'. Классический пример: что такое T(a); если T?—?некоторый тип? С одной стороны, это как бы объявление переменной с именем a, тип которой задан как T. С другой?—?конструкцию можно трактовать как преобразование типа уже объявленной где-то ранее переменной a к типу T. Все дело в том, что в Си++ статус операторов и объявлений полностью уравнен; последние даже и называются declaration-statements?—?операторы-объявления, то есть традиционные операторы и объявления могут записываться вперемежку. Все же радости с круглыми скобками перекочевали в Си++ прямо из Си, в котором типы конструируются подобно выражениям, и тривиальное объявление можно задать либо как 'int a;', либо как 'int(a);'. Все это понятно, но от этого не легче. И такой язык любят миллионы программистов?! Мир сошел с ума. Яду мне, яду!..

Смысл правил разрешения неоднозначностей сводится, по существу, к поразительной фразе, простодушно выведенной в 'Зеленой книге': 'если конструкция выглядит как объявление, то это и есть объявление. В противном случае это оператор'. Иными словами, чтобы разрешить неоднозначность, следует рассмотреть всю конструкцию целиком; фрагмент 'T(a)' для анализа недостаточен?—?за ним сразу может следовать либо точка с запятой, тогда выбор делается в пользу объявления, либо