Б. Страуструп - Дизайн и Эволюция C++. 2006 (1160775), страница 30
Текст из файла (страница 30)
В качестве решения (будущего) втой проблемы в С++ была представлена концепция параметризованных типов: уо)б а() ( всас)г(р1апе*) св; св.рцвЬ(пеы ВааЬ37Ь)г // правильно: БааЬ37Ь вЂ” это объект типа р1апе св.рцвЬ(пеы БааЬ900); // ошибка: несоответствие типов // передан саг, ожидался р1апе св.рор()->га)геогг()г // во время исполнения проверка не нужна св.рар()->та)геогг()г // во время исполнения проверка не нужна ) Такие ошибки было решено обнаруживать именно на этапе компиляции потому, что, как было подмечено, С++ часто используется для написания программ, исполняемых в отсутствие программиста. Статический контроль типов мы принципиально считали не просто методом повышения производительности, а лучшим способом в максимально возможной мере гарантировать правильность программы. Но главная причина, по которой я полагаюсь на статически контролируемые интерфейсы, — моя твердая убежденность, что программа, составленная из статически проверенных частей, может лучше отразить хорошо продуманный дизайн, нежели программа, зависящая от слабо или динамически типизированных интерфейсов.
При этом необходимо помнить, что не всякий интерфейс поддается одной лишь статической проверке, а из того, что программа прошла статический контроль, не следует, что в ней не осталось ошибок. В статье «Ю))аг(зу» перечислены три изъяна С++: о «Аг)а, С(ц и М1 поддерживают параметризованные типы. В С++ этого нет. Там, где необходимо, параметризованные классы «имнтируются» с помощью макросов. Ясно, что параметризованные классы были бы очень полезны в С++.
Встроить соответствующие Статья тгМ/1эа11з?» 11ИИИИИКП средства в компилятор легко, но современная система программирования для С++ недостаточно развита, чтобы поддержать их без заметных расходов и неудобств. Употребление параметризованных типов не должно приводить ни к каким новым накладным расходам по сравнению с обычнымиэ; ш «по мере увеличения размера программы и особенно в случае интенсивного использования библиотек возрастает значимость стандартной обработки. ошибок (ипи, в более общем смысле, «исключительных ситуацийэ). В Або, А)по!68 и С!а таким стандартом является механизм обработки исключений. Увы, в С++ его нет. Там, где необходимо, исключения подменяются указателями на функции, кобъектами исключенийт, «ошибочными состояниямиь и библиотечными функциями втдпаг и Топабглр. В обычной ситуации этого недостаточно.
С помощью этих средств не удается даже сформулировать единый подход к обработке ошибокм ш кпринимая во внимание это объяснение, представляется очевидным, что наследование классом В двух классов А1 и А2 могло бы быть полезным. Этот механизм называется множественным наследованием». Все три возможности были упомянуты в контексте построения лучших (то есть более общих и более гибких) библиотек. Все они вошли теперь в С++ (шаблоны, см. главу 15; исключения, см.
главу 16; множественное наследование, см. главу 12). Отмечу, что добавление множественного наследования и шаблонов рассматривалось в качестве вероятных направлений развития С++ еще в работе [Ягоизтгпр, 1982Ъ~. Там же, как одна из возможностей, упоминалась обработка исключений. Как обычно, я подчеркнул, что требования к эффективности по скорости и памяти, а равно к возможности сосуществовать с другими языками в широко распространенных системах ограничивают язык, но, с другой стороны, язык, претендующий на звание «универсального», не может отказаться от этих требований.
Глава 4. Правила проектирования языка С++ Если карта не соответствует местности, доверяй местности. Заповедь швейцарской армии 4.1. Правила и принципы Чтобвя с языком программирования было полезно и приятно работать, он должен быть создан на основе некоего обшего взгляда, определяющего проектирование индивидуальных особенностей. Для С++ такой взгляд оформлен в виде набора правил и ограничений. Я употребляю слово «правила», поскольку понятие «принципы» кажется мне излишне претенциозным в контексте такой дисциплины, как проектирование языков программирования, где настоящих научных принципов не так уж и много. Кроме того, для многих людей словосочетание «научный принцип» прочно ассоциируется с отсутствием исключений, а зто вовсе нереально. На самом деле, если правило и практика вступают в конфликт, то, уверен, уступить должно правило.
Нижеизложенные правила нельзя применять бездумно, но нельзя и заменить их ни к чему не обязывающими лозунгами. Как проектировшик языка, я видел свою работу в том, чтобы определить, какие задачи следует и можно решать в рамках С++ и как поддержать баланс между различными правилами при проектировании конкретного средства. Правила служили путеводной нитью при работе над конкретными средствами.
Однако общий план усовершенствований был продиктован фундаментальными целями С++ (см. табл. 4.1). Таблица 4.1 Цели С++ делает программирование более приятным занятием для серьезных программистов С++ — зто язык программирования общего назначения, который С пунше С С поддерживает абстракции данных ц поддерживает обьектно-ориентированное программирование Я разбил все правила на четыре большие группы. Первая содержит общие критерии языка в целом — настолько общие, что к отдельным возможностям они ЛИИИИИИБ Правила и принципы 42.
Общие правила Самые общие и важные правила С++ мало связаны с техническими вопросами (см. табл. 4.2). Основной упор в них сделан на интересах сообщества пользователей. Природа С++ в значительной мере определена моим желанием помочь современному поколению системных программистов в решении актуальных задач. Подчеркну, что смысл слова «современный» изменяется со временем, а значит, С+ь должен эволюционировать, чтобы соответствовать потребностям своих пользователей; он не может быть определен раз и навсегда. Таблица 4.
2 Общие правила Эволюция С++ должна определяться реальными задачами Не устремляться в бесплодную погоню за совершенством С++ должен быть полезен сейчас Каждое средство должно иметь достаточно ясную реализацию Всегда оставлять путь для перехода С++ — вто язык, а не законченная система Предоставлять всестороннюю поддержку для каждого поддерживаемого стиля программирования Ничего не заставлять делать насильно Эволюция Сч-ь должна определяться реальными задачами. В информатике, как и во многих других областях, можно наблюдать, как люди ищут задачу, к которой можно было бы применить свое любимое решение.
Я не знаю безошибочного способа уберечься от субъективности при определении того, чту же является действительно важным, по точно знаю, что многие возможности, которые мне предлагали включить в язык, не уживаются с обшей идеологией С++ и зачастую не нужны программистам, работающим над реальными проблемами. Единственным мотивом для внесения в С++ каких-либо изменений является продемонстрированная несколькими независимыми программистами недостаточная для решения их задач выразительность языка. Если только возможно, я привлекаю пользователей к поиску решения н воплощению его в жизнь.
не относятся. Во вторую группу включены правила, относящиеся к роли С++ как инструмента поддержки проектирования. В третьей группе собраны аспекты, касающиеся технических, формирующих облик языка деталей. А правила из четвертой группы акцентируют внимание на роли Счн» как языка для низкоуровневого программирования. Конечно, формулировки отточены уже задним числом, но эти правила определяли ход моих мыслей еше до завершения работы над первой версией С++ в 1985 г., а многие из них, как упоминалось в предыдущих главах, легли в основу исходной концепции С цчт1т С1аззез.
ПИИИИИИ61 Правила проектирования языка С++ Не устремляться е бесплодную погоню за совершенством. Любой язык программирования несовершенен. И никогда не будет идеального языка, поскольку задачи и системы не стоят на месте. Годами шлифовать язык, пытаясь создать идеальную модель, — значит лишать программистов «сх преимуШеств, которые появились за это время.
Тем самым проектировшик языка оставляет себя без обратной связи, и язык может развиться до такой степени, что станет уже никому не нужен. С другой стороны, программисты тратят больше всего времени на модификацию старого кода или попытки сопряжения с ним новых программ. Для работы им нужна стабильность. Бели язык реально используется, то в нем неприемлемы радикальные изменения.
Даже относительно мелкие модификации трудно внести, це навредив пользователям. Поэтому решение пойти на серьезное усовершенствование должно опираться на надежную обратную связь с аудиторией, и принимать ту или иную поправку нельзя без серьезного рассмотрения вопросов совместимости, перехода на новую версию и обучения. По мере того как язык становится все более зрелым, любым изменениям в нем следует предпочитать альтернативы в виде инструментальных средств, специальных приемов и библиотек. Не каждую задачу нужно решать на С-н-, и не каждая проблема, имеющаяся в С++, настолько серьезна, чтобы заниматься ею. Например, не следует включать в сам язык средства для сопоставления с образцом или доказательства теорем, а хорошо известные недостатки С++, связанные с неудачно выбранными приоритетами операций (см. раздел 2.6.2), лучше не пытаться исправлять, а ограничиться предупреждениями компилятора. С++ должен быть полезен сейчас.
Многие занимаются программированием для решения сиюминутных задач, работают на довольно слабых компьютерах с устаревшими ОС и инструментальными средствами. Некоторым программистам не хватает формального образования. У многих нет времени повышать свою квалификацию. Таким образом, С++ должен быть полезен любому, кто обладает средней квалификацией и обычным компьютером. Хотя временами меня н подталкивали к этому, я никогда не собирался бросить таких пользователей на произвол судьбы и начать ориентироваться только на системы высшего класса и вкусы профессиональных ученых в области информатики.
Смысл этого правила — как и большинства других — изменяется со временем и в какой-то мере с распространением С++. Сейчас доступны более мошные компьютеры, растет и число программистов, знакомых с базовыми концепциями и методами, на которые опирается С++. А когда человек ставит перед собой более амбициозные цели, изменяются и задачи, с которымн он сталкивается.
Отсюда следует, что сегодня можно и должно подумать о средствах, для которых требуются больше вычислительных ресурсов и более высокая квалификация программистов. Прнлгерами могут служить обработка исключений (см. главу 16) и идентификация типов во время исполнения (см. раздел 14.2). Каждое средство должно иметь достаточно ясную реализицию. Для правильной и эффективной реализации любого средства не должно возникать нужды в сложных алгоритмах. В идеале должны существовать очевидные стратегии анализа и генерации кода, достаточно удобные для применения на практике.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
