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

Такой подход оказывает огромное влияние на способ проектирования систем и на выбор языковых средств. Язык с динамическими типами, вроде Smalltalk, упрощает проектирование и реализацию библиотек, позволяя отложить проверку типов до исполнения программы. Например (используем синтаксис С++):

void f О только динамический контроль типов, это не С++ {

stack cs;

cs.push(new Saab900);

cs.pop()->takeoffО; Увы! Ошибка времени исполнения.

В классе саг нет метода takeoff

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

void g() {

stackCplane*) cs;

cs.push(new Saab37b); правильно: Saab37b - это объект типа plane cs.push(new Saab900); ошибка: несоответствие типов передан car, ожидался plane

cs.pop()->takeoff(); во время исполнения проверка не нужна cs.pop()->takeoffО; во время исполнения проверка не нужна

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

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

В статье Whatis? перечислены три изъяна С++:

□ Ada, Clu и ML поддерживают параметризованные типы. В С++ этого нет. Там, где необходимо, параметризованные классы имитируются с помощью макросов. Ясно, что параметризованные классы были бы очень полезны в С++. Встроить соответствующие

средство в компилятор легко, но современная система программирования для С++ недостаточно развито, чтобы поддержать их без заметных росходов и неудобств. Употребление параметризованных типов не должно приводить ни к каким новым накладным расходам по сравнению с обычными ;

□ по мере увеличения размера программы и особенно в случае интенсивного использования библиотек возрастает значимость стандартной оброботкиошибок (или, в более общем смысле, исключительных ситуаций ). В Ada, Algol68 и Clu таким стандартом является механизм обработки исключений. Увы, в С++ его нет. Том, где необходимо, исключения подменяются указателями но функции, объектами исключений , ошибочными состояниями и библиотечными функциями signal и long jmp. В обычной ситуации этого недостоточно. С помощью этих средств не удается даже сформулировоть единый подход к обработке ошибок ;

□ принимая во внимание это объяснение, представляется очевидным, что наследование классом В двух клоссов А1 и А2 могло бы быть полезным. Этот механизм называется множественным наследованием .

Все три возможности были упомянуты в контексте построения лучших (то есть более общих и более гибких) библиотек. Все они вошли теперь в С-ы- (щаблоны, см. главу 15; исключения, см. главу 16; множественное наследование, см. главу 12). Отмечу, что добавление множественного наследования и шаблонов рассматривалось в качестве вероятных направлений развития С-1-+ еще в работе [Stroustrup, 1982Ь]. Там же, как одна из возможностей, упоминалась обработка исключений.

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

Глава 4. Правила проектирования языка С++

Если карта не соответствует местности, доверяй местности. Заповедь швейцорской армии

4.1. Правила и принципы

Чтобы с языком программирования было полезно и приятно работать, он должен быть создан на основе некоего общего взгляда, определяющего проектирование индивидуальных особенностей. Для С-и- такой взгляд оформлен в виде набора правил и ограничений. Я употребляю слово правила , поскольку понятие принципы кажется мне излишне претенциозным в контексте такой дисциплины, как проектирование языков программирования, где настоящих научных принципов не так уж и много. Кроме того, для многих людей словосочетание научный принцип прочно ассоциируется с отсутствием исключений, а это вовсе нереально. На самом деле, если правило и практика вступают в конфликт, то, уверен, уступить должно правило. Нижеизложенные правила нельзя применять бездумно, но нельзя и заменить их ни к чему не обязывающими лозунгами. Как проектировщик языка, я видел свою работу в том, чтобы определить, какие задачи следует и можно решать в рамках C-i-i- и как поддержать баланс между различными правила.ми при проектировании конкретного средства.

Правила служили путеводной нитью при работе над конкретны.ми средства-.ми. Однако общий план усовершенствований был продиктован фунда.ментальны-.ми целя.ми С-и- (см. табл. 4.1).

Таблица 4.1

Цели

С++ делает программирование более приятным занятием для серьезных программистов С++ - это язык программирования общего назначения, который

□ лучше С

□ поддерживает абстракции данных

□ поддерживает объектно-ориентированное программирование

Я разбил все правила на четыре большие группы. Первая содержит общие критерии языка в целом - настолько общие, что к отдельным возможностям они