По рукам!
У кого-то из классиков есть забавная шутка (за точность цитаты не ручаюсь, но смысл передан верно): "Системные программисты не вполне понимают, за что им платят большую зарплату: ведь они выполняли бы свою работу и бесплатно. Правда, у них хватает ума не говорить об этом своему начальству". Это очень точное наблюдение — прямо про нас, только без "большой зарплаты".
Характер условий, предлагаемых бельгийцами, был, видимо, типичен для тогдашних отношений с иностранными фирмами: они передавали нам несколько рабочих станций Sun 3/60 на процессоре Motorola 68020 (которые к тому времени уже морально устарели и самой фирмой попросту списывались) и обещали платить… не скажу сколько, но, поверьте, очень и очень небольшие деньги — даже по тогдашним российским меркам.
Вообще-то, это не очень вязалось с обликом солидной фирмы, но осознание пришло гораздо позже. Да, еще: те станции, на которых мы должны были работать, передавались нам не просто так — они шли в счет оплаты за нашу работу! Мы оказались как бы должны им, еще не приступив к делу… Впоследствии то же произошло со SparcClassic. Когда на 3/60 стало совсем невозможно работать (примерно как если на XT пытаться редактировать графические изображения), нам перевели деньги на покупку этой самой младшей модели семейства Sparc с минимальной комплектацией, внеся ее стоимость в оплату проекта.
Естественно, результат работы становился собственностью фирмы, а с нас взяли подписку о неразглашении, согласно которой в течение всего срока действия контракта мы не имели права не только говорить об условиях работы и названии фирмы, но и вообще рассказывать о том, что мы делаем. Говорят, некоторые компании оговаривают и более суровые условия: скажем, после окончания действия контракта разработчик в течение некоторого времени не имеет права работать над аналогичными проектами. Какое счастье, что бельгийцы до этого не додумались — мы бы подмахнули и такое…
Можно сколько угодно смеяться над нашей наивностью и недальновидностью, но когда вот сейчас, наяву, предлагается в точности та работа, о которой (простите за высокопарность) мечтал всю жизнь…
Кажется, мы и сейчас приняли бы подобные условия (шутка).
Глаза боятся, а руки делают
Не знаю, решились бы мы на этот проект, если бы сразу представляли (так, как знаем сейчас) его истинную трудоемкость. Тогда язык Си++, судя по учебным пособиям, казался нам… да, непростым для компиляции, с корявым и неоднозначным синтаксисом, сильно усложненной семантикой традиционных конструкций, но вполне сравнимым, например, с объектной версией Паскаля фирмы Borland. Так что срок, названный шефом, поначалу не вызвал у нас протеста. Однако чтение первой же действительно серьезной и подробной книги — перевода авторского определения языка[1], предложенного в качестве начальной версии для его стандартизации, повергло нас в ужас и панику. Казалось, это безумие невозможно реализовать вообще! Тогда мы поняли настоящую цену учебникам типа "Язык XXX за двадцать один день" или "YYY — это просто!". Подобные тексты (сами по себе, быть может, и неплохо написанные) оставляют за своими рамками настолько обширные области языка, избегают касаться стольких его тонкостей и особенностей, что в голове у читателя-программиста формируется зачастую усеченный и выхолощенный образ инструмента, который он собирается использовать.
Вообще, у автора вызывает некоторую настороженность, когда о сложных вещах пытаются говорить упрощенно (это касается не только программирования). Задачи, решаемые современными программными системами, очень и очень сложны. Для их создания приходится использовать адекватные инструменты, которые не могут не соответствовать сложности и ответственности задач и потому объективно не могут быть простыми. Поэтому писать о Си++ в стиле "Откройте файл myprog1.cpp с компакт-диска, прилагаемого к книге, и нажмите Ctrl-F9. Поздравляем! Вы выполнили вашу первую программу на Си++!" — недопустимая профанация предмета.
С тех пор мы считаем, что настоящее пособие по сложному современному языку программирования общего назначения (уровня Си++ или Ada95) должно иметь форму, близкую упоминавшейся выше книге Эллис и Страуструпа,-- комментированный стандарт. Только такая книга может дать читателю настоящее понимание языка. Да, читать и пытаться понять строгий, сложно построенный, местами даже занудный текст будет весьма непросто — но кто сказал, что профессия программиста проста? Мы обязательно сделаем такую книгу по Си++, когда его Стандарт, наконец, будет принят.
Стандарт принят в 1998 году — уже почти три года назад, а обещанных комментариев до сих пор нет… Собственно текст Стандарта я практически полностью перевел, надо бы засесть и за комментарии. Однако одному мне не справиться… Саша Кротов, где ты!?..
Мы подошли к делу серьезно. Три или четыре месяца мы практически не программировали. Мы изучали Эллис и Страуструпа ("Зеленую книгу") вдоль и поперек и во всех мыслимых направлениях, продумывали общую конфигурацию компилятора, выбирали построение основных структур данных и важнейших алгоритмов, предлагали и обсуждали проектные и технические решения и писали проект.
Прекрасно помню чувство гордости, которое мы испытали, увидев наглядное свидетельство наших трудов — увесистый том, привезенный Вальтером, красиво отформатированный, распечатанный на лазерном принтере (у нас их тогда и в помине не было) и даже, кажется, переплетенный. Сейчас, когда прошло уже около трех лет, очень многие наши проектные решения кажутся прямолинейными, наивными и даже неверными; некоторые пришлось менять уже в процессе реализации, но, тем не менее, проект дал необходимую основу для работы.
Этот текст, кажется, произвел достаточное впечатление на бельгийцев; они вполне убедились в уровне нашей квалификации. Тогда показалось удивительным, но некоторых простых вещей они просто не знали: например, что typedef-объявление не вводит новый тип, конструкции extern "С" могут быть вложенными и т.д. Не говоря уже о более специфических аспектах. Когда мы описывали в проекте технику компиляции вызовов, мы употребили термин "thunk" (короткий код для вычисления фактического параметра). Оказывается, они, сделавшие несколько коммерческих компиляторов, не знали, что это такое! С удовольствием и тайным злорадством я выписал из классической книги Гриса[2] и послал им большую цитату, объясняющую этот термин…
Первые радости
Начнем с синтаксиса (самого, казалось бы, простого аспекта, однако борьбой с ним завершаются попытки очень многих). Несколько первых впечатлений. Во-первых, язык просто очень большой. Это означает, что синтаксические таблицы — составленные вручную или построенные каким-нибудь генератором распознавателей, вроде YACC, будут довольно велики, что, естественно, замедлит скорость синтаксического разбора.
Однако при внимательном анализе оказывается, что в языке имеется сравнительно большое число «микро»-регулярностей — часто повторяющихся устойчивых последовательностей лексем. Например, пары пустых скобки: (), [], пустой список параметров (void), завершитель списка параметров ...) встречаются очень часто. После служебных слов if, switch, while всегда должна стоять левая круглая скобка, после break и continue — точка с запятой, а после слова goto располагаются идентификатор и точка с запятой. Таких регулярностей набирается несколько десятков, так что если рассматривать их как отдельные лексемы, объем синтаксиса заметно сокращается. Введение каждой такой "суперлексемы" экономит по крайней мере одно обращение синтаксического анализатора к таблице разбора. Усложнение распознавателя лексем (сканера), вынужденного составлять суперлексемы из пар или троек обычных лексем, при этом получается весьма незначительное; более того, если сканер во время одного вызова распознает, например, не только служебное слово switch, но и левую круглую скобку, идущую за ним, получится экономия и на числе обращений к сканеру!
1
Эллис М., Строуструп Б. Справочное руководство по языку программирования C++ с комментариями: Пер. с англ.-- М.: Мир, 1992 — 445 с., илл. ISBN 5-03-002868-4.
2
Грис Д. Проектирование компиляторов для цифровых вычислительных машин: — Пер. с англ.-- М.: Мир, 1969.