Б. Страуструп - Дизайн и Эволюция C++. 2006 (1160775), страница 29
Текст из файла (страница 29)
Эта работа имеет больше общего с инженерной практикой, социологией, философией, нежели с математикой. Оглядываясь назад, я жалею, что не нашел способа формализовать правила преобразования типов и сопоставления формалъных и фактических аргументов. У меня есть подозрение, что никакой формализм не смог бы справиться с крайней нерегулярностью правил С в отношении встроенных типов и операторов. У дизайнера языка есть большое искушение предоставить специальные средства там, где пользователям пришлось бы искать обходные пути, Недовольство по поводу отказа добавлять что-то обычно гораздо сильнее, чем жалобы на то, что чдобавлена еще одна бесполезная возможностьа.
Это серьезная проблема и для комитетов по стандартизации (см. раздел 6.4), и худший вариант в этом смысле— культ ортогональности. Многие думают, что если от добавления некоей возможности язык становится более ортогональным, то и спорить больше не о чем. Обычно же, вопреки всем благим намерениям относительно ортогональности, определение Рождение С++ ШИИИИИИЫ комбинации средств все же требует дополнительной работы над справочным руководством и руководством пользователя. Чаще всего реализация комбинации, которую предписывают идеалы ортогональности, оказывается сложнее, чем многие себе представляют.
В случае С++ я всегда учитывал, во что (с точки зрения времени и памяти) обойдется ортогональность тем, кто не исполъзует данную комбинацию. Если цену нелъзя было, по крайней мере, в принципе свести к нулю, то я очень неохотно шел на добавление новой возможности, какой бы ортогональной она ни была. Мне казалось, да и сейчас кажется, что многие языки программирования и инструментальные средства дают решения, которые так и влекут за собой неприятности, и я ни в коем случае не хотел допустить, чтобы мою работу постигла та же участь. Поэтому я читаю литературу по языкам программирования, принимаю участие в дискуссиях на эту тему, но в основном ишу идеи для решения проблем, с которыми я и мои коллеги сталкивались в реальных приложениях.
В других языках скрыта масса вдохновляющих возможностей, только надо тШательно просеять их, чтобы не поддаться соблазну, утратив чувство меры, н избежать внутренних противоречий. Основными источниками идей для С++ были 81пш!а, А18о!68, а позже — С1п, Ада и М).. Ключ к хорошему дизайну — глубокое понимание стоящих перед языком задач, а не включение самых передовых идей.
3.14. Книга «Язык программирования С++» Осенью 1984 г. сидевший в соседнем с моим кабинете Эл Ахо предложил мне написать книгу по С++, организованную по образу и подобию книги Брайана Кернигана и Денниса Ричи «Язъ1к программирования С» ]Кегп(8]тап, 1978]. В основу труда должны были лечь мои статьи, внутренние отчеты и справочное руководство по С++.
Работа над книгой заняла девять месяцев. Я закончил ее в середине августа 1985 г., а первые экземпляры появились в середине октября. В предисловии упоминаются те, кто внес наибольший вклад в С++: Том Каргилл, Джим Коплиен, Стью Фельдман, Сэнди Фразер, Стив Джонсон, Брайан Керниган, Барт Локанти (Вагг ?.осапг]т1), Дуг Макилрой, Деннис Ричи, Ларри Рослер, Джерри Шварц и Джонатан Шапиро. «С++ проектировался прежде всего для того, чтобы автору и его друзьям не приходилось программировать на ассемблере, С или современных языках высокого уровня. Основная задача С++ — сделать написание хороших программ более простым и приятным занятием для профессионального программиста», — говорилось вначале. Объект моей работы — человек, индивидуум (неважно, является ли он членом какого-то коллектива или нет), программист.
С годами я становился все более привержен этой идее и еше сильнее подчеркнул ее во втором издании [2пт]], где гораздо глубже обсуждались вопросы проектирования и разработки программного обеспечения. Книга «Язык программирования С++» представляла собой определение языка С++ и введение в него.
Она писалась с твердой решимостью не отдавать предпочтение никаким особым приемам программирования в ушерб всем прочим. Книга <«Язык программирования С++ ПИИ>ВИКИ Точно так же, как я боялся внести ограничения в язык по невежеству, я не хотел, чтобы эта книга была манифестом моих персоналъных предпочтений.
3.15. Статья иФпаб9? 11 После выпуска версии 1.0 и отправки оригинал-макета книги в издательство у меня появилось время вернуться к рассмотрению крупных вопросов и документировать весь ход проектирования. Как раз в это время мне позвонил из Осло Карел Бабчиски, председатель Ассоциации пользователей Япш1а (А8(!), и пригласил выступить с докладом о С++ на конференции А81) 1986 г. в Стокгольме. Конечно, я хотел поехать, но был обеспокоен тем, что презентация С++ на конференции по Япш!а может быть расценена как вульгарная самореклама и попытка отвратить пользователей от этого уважаемого языка.
В конце концов я сказал: «С++ — не Япш!а, так почему пользователи Япш!а захотят слушать о нем?» На зто Бабчиски ответил: «Да мы же не цепляемся за синтаксис». Это дало мне возможность написать не только о том, что такое С++, но и о том, чем он предположительно станет, и о том, где пришлось отступить от идеалов. В результате появилась статья «эйгЬаг Ь ОЬ!ес1-Опеп1ед Ргойгаппшпй» («Что такое объектно-ориентированное программирование»), 18ггоцэггпр, 1986Ъ1. Развернутый вариант работы представлен на первой конференции ЕСООР в июне 1987 г. в Париже.
В этой статье впервые изложены те приемы и методы, поддержку которых должен был обеспечить С++. Все предшествующие презентации ограничивались описанием тех возможностей, которые уже реализованы и применяются. В статье «»ьгЬас1з7» был сформулирован ряд проблем, которые, как я надеялся, сможет решить язык, поддерживающий абстракцию данных и объектно-ориентированное программирование. Здесь также приводились примеры средств, которые я считал необходимыми.
В работе вновь подчеркивалась природа С++ как языка, поддерживающего несколько парадигм: «Объектна-ариенгираваннав программирование — эта программирование с применением наследования. Абстрагирование данных - это программирование с использованием определенных пользователем типов. За немногими исключениями, объектно-ориентированное программирование может и должно быть подмножествам абстрагирования донных. Чтобы этн методы были эффективны, необходима надлежащая поддержка. Поддержка абстрагирования данных требует языковых средств, а для объектно-ориентированного программирования нужна вще и поддержка са стороны среды.
Чтобы претендовать на звание языка общего назначения, язык, поддерживающий абстрагирование донных или объектно-ориентированное программирование, должен эффективна работать с распространенной аппаратурой». Особо говорилось о важности статического контроля типов. Другими словами, модель наследования и контроля С++, скорее, построена на базе Яшп!а, чем 5ша!! га1!г: «Класс в 5кпа)а или С++ определяет неизменный интерфейс к множеству объектов, принадлежащих любому производному классу, тогда как в 5гпа!!га!!г класс определяет начальный набор операций с объектами !любага подкласса!.
Иначе говоря, в 5гла!йа!к класс — минимальная спецификация и пользователь может попробовать выполнить неуказанные операции, в га время Рождение С++ ИИИИИИИВ как в С++ класс — точная спецификации и гарантируется, что компилятор не пропустит опера- ций, не указанных в объявлении класса>. Такой подход оказывает огромное влияние на способ проектирования систем и на выбор язъ)ковых средств.
Язык с динамическими типами, вроде Виспа!1(а)к, упрощает проектирование и реализацию библиотек, позволяя отложить проверку типов до исполнения программы. Например (используем синтаксис С++): нога 1() // только динамический контроль типов, это не О++ влас)г св; св.рцвЬ(пеы ВааЬ900)) св.рор()->са)геоьь()г // увы! Ошибка времени исполнения. // В классе саг нет метода са)геог1 ) Такое отложенное обнаружение ошибок типизации было сочтено в С++ неприемлемым. Но следовало найти способ добиться удобства обозначений и построения библиотек нс хуже, чем в языках с динамическими типами.