Б. Страуструп - Дизайн и Эволюция C++. 2006 (1160775), страница 32
Текст из файла (страница 32)
Расширение С++ в направлении поддержки методик проектирования, ориентированных на «улучшенный С», абстракцию данных и объектно-ориентированное программирование, помогло избежать искушения сделать язык «всем для всех», и в то же время сохранило постоянный стимул для улучшений. Предостпавлять средстви для организации программ. По сравнению с С, С++ помогает организовать программу так, чтобы ее было легко писать, читать и сопровождать. Я считал, что осуществлять вычислительную работу с С очень удобно.
Конечно, у меня есть свои мысли, как можно было бы улучшить выражения и предложения С, но я решил сосредоточить усилия на другом. Когда кто-то предлагал новый вид выражений или предложений, я оценивал его по тому, может ли оно улучшить структуру программы или просто слегка упростит некоторые вычисления. За немногими исключениями (например, разрешение включать объявление при первом обращении к переменной, см.
раздел 3.11.5), выражения и предложения С не подвергались модификациям. точно говорить то, что имеется в виду. Фундаментальная проблема низкоуровневых языков программирования заключается в следующем. Имеется огромный разрыв между тем, что люли говорят друг другу в беседе, и тем, что они могут выразить на данном языке. Базовая структура программы теряется за нагромождением битов, байтов, указателей, циклов и т.д. Основное средство преодоления такого разрыва — сделать язык более декларативным.
Почти все предоставляемые С++ средства предполагают объявление чего-либо, а затем использование дополнительных конструкций для проверки непротиворечивости, обнаружения глупых ошибок н генерирования оптимизированного кода. Там, где нельзя воспользоваться декларативной структурой, может помочь явная нотация. Хорошими примерами служат операторы выделения и освобождения памяти (см. раздел 10.2) и новый синтаксис приведения типов (см.
раздел 14.3). Концепция прямого и явного выражения намерений на первых порах формулировалась так: «позволить выразить все важное самим языком, а не с помощью комментариев или трюков с макросами». Отсюда следует, что язык в целом Правила поддержки проектирования МИИИИИИБ и система контроля типов в особенности должны быть более выразительными, чем в предшествующих языках общего назначения.
Все возможности должны быть адекватпьс Недостаточно просто дать пользователю некоторое средство или порекомендовать способ решения определенной задачи. Предлагаемый вариант не должен требовать слишком больших затрат. В противном случае совет звучит, как издевательство. Конечно, в ответ на вопрос «Как лучше всего добраться до Мемфисами» можно посоветовать нанять реактивный самолет, но вряд ли это предложение устроит кого-нибудь, кроме миллионеров. Любое средство включалось в С++, только когда было невозможно добиться той же функциональности с меньшими затратами.
Мой опыт показывает, что при наличии выбора между эффективностью и изяществом, большинство программистов предпочтет эффективность. Например, встраиваемые функции были введены для того, чтобы, с одной стороны, уменьшить плату за пересечение границ защиты, с другой — чтобы предложить улучшенную альтернативу макросам. Конечно, в идеале средство должно быть одновременно и изящным, и эффективным. Там же, где зто не получалось, средство либо не предоставлялось вовсе, либо — если без него нельзя было обойтись — делался выбор в пользу эффективности. Вше<ее включить полезную возможность, чем предотвращать неправилыгое испоиьзование.
Плохие программы можно писать на любом языке. Важно уменьшить шансы на случайное неправильное применение тех или иных возможностей. Поэтому я потратил много усилий, чтобы принимаемое по умолчанию поведение конструкций С++ было либо разумно, либо приводило к ошибке компиляции. Например, по умолчанию проверяются все аргументы функции.
По умолчанию же все члены класса являются закрытыми. Однако язык, предназначенный для системного программирования, не может помешать решительно настроенному программисту «обмануть» систему, поэтому лучше направить силы на разработку средств, помогающих писать хорошие программы, чем не дающих написать плохую программу. Похоже, что со временем программисты обучаются. Это вариант старого лозунга, пришедшего еще из С, — «доверяй программисту». Различные способы контроля типов и правила ограничения доступа предназначены для того, чтобы разработчик класса мог ясно выразить, чего он ожидает от пользователей с целью предотвращения случайных ошибок, но никак не с целью воспрепятствовать преднамеренному нарушению (см.
раздел 2.10). Поддерживапгь сборку программ из независимо разработанных частей. Чем сложнее система, чем больше программа, чем ограничениее ресурсы, тем более обширная поддержка необходима программистам. При проектировании С++ много усилий было потрачено на то, чтобы предоставить поддержку в описанных условиях.
Большие и сложные приложения должны составляться из независимых частей, иначе управлять ими будет невозможно. Для такой цели подойдет все, что позволяет разрабатывать компоненты независимо, а затем использовать их в крупной системе не модифицируя. Эволюция С++ во многом проходила под влиянием этой идеи. Классы работают в данном направлении, а абстрактные классы (см.
раздел 13.2.2) явно поддерживают разделение интерфейса и реализации. На самом деле классы можно использовать для выражения широкого спектра стратегий сопряжения [зсгоцзггор, 1990Ь1. Исключения ИИИИИИИ61 Правила проектирования языка С++ позволяют вынести обработку ошибок из библиотеки (см. раздел 16.1), шаблоны обеспечивают композицию с помощью подстановки типов (см. разделы 15.3, 15.6 и 15.8), пространства имен решают проблему непреднамеренного совмещения имен (см. раздел 17.2), а идентификация типов во время выполнения отвечает на вопрос, что делать, если истинный тип обьекта «потерялся» где-то в библиотечных функциях (см.
раздел 14.2.1). Из утверждения «программисту нужна тем большая поддержка, чем крупнее система» следует, что для обеспечения эффективности нельзя полагаться лишь на методы оптимизации кода, которые хорошо работают только для сравнительно небольших программ. Стало быть, решение о размещении объекта в памяти должно приниматься на основе отдельно взятой единицы трансляции, а виртуальные функции должны компилироваться в эффективный код без расчета на глобальную оптимизацию, в ходе которой обрабатываются все единицы трансляции.
Это верно, даже если в качестве эталона эффективности берется С. Последующая оптимизация возможна на этапе, когда доступна информация обо всей программе. Например, если в программе появляется вызов виртуальной функции, иногда есть возможность (в отсутствии динамического связывания) определить, какая же функция на самом деле вызывается. В таком случае вызов виртуальной функции можно заменить вызовом обычной или даже встроить такой вызов.
Существуют компиляторы С++, способные на такое. Однако для генерирования эффективного кода подобные оптимизации не являются необходимыми, их стоит считать лишь дополнительным удобством, когда эффективность исполнения важнее времени компиляции, а от динамического связывания классов можно отказаться. Даже если такая глобальная оптимизация признается неразумной, вызов виртуальной функции все равно можно оптимизировать, когда она вызывается для объекта известного типж еше в С(гопс версии 1.0 была возможность осуществлять это.
Поддержка больших систем обсуждается в главе 8. 4.4. Технические правила Следующие правила говорят о способах выражения в С++ (см. табл. 4.4). Таблица 4.4 Технические правила Никаких неявных нарушений статической системы типов Предоставлять для определенных пользователем типов такую же полноценную поддержку, как для встроенных Локальность — это прекрасно Избегать зависимости от порядка Если есть сомнения, выбирать такой вариант средства, которому легче обучить Синтаксис важен, хотя бывает и нелогичным Использование препроцессора должно быть исключено Пикагп«х неявных нарушений статической системы типов.
При создании каждого объекта указывается его тип: с1оцЬ1е, с1таг* или с11а1 Ьий йег. Если способ Технические правила ИИИИИИЫИ использования объекта противоречит его типу, то говорят о нарушении правил контроля типов. Язык, где такие нарушения в принципе невозможны, называется сильно типизированным. Язык, в котором каждое такое нарушение обнаруживается во время компиляции, называется статически сильно типизированным. С++ наследовал от С такие свойства, как объединения (цшопз), приведение типов и массивы, которые не позволяют обнаружить все нарушения во время компиляции.
Сегодня в С++ не допускаются неявные нарушения правил контроля типов. Это означает: для того чтобы обойти систему, вам придется явно использовать объединение, приведение типов или массив, явно сказать, что аргумент функции не должен контролироваться, или явно воспользоваться небезопасной С-компоновкой. При любом использовании небезопасных средств на этапе компиляции может выдаваться предупреждение. Еще важнее то, что теперь в С++ имеются средства, которые удобнее эквивалентных небезопасных средств и не уступают им в эффективности.
В качестве примера можно привести производныс классы (см. раздел 2.9), стандартный шаблон класса массива (см. раздел 8.5), типобезопасную компоновку (см. раздел 11.3) и динамически проверяемые приведения типов (см. раздел 14.2). Из-за требований совместимости с С и уважения к сложившейся практике путь к такому положению был длинным и тернистым; большинству программистов еше только предстоит усвоить более безопасные приемы. Всюду, где возможно, проверки производятся на этапе компиляции. Если чтото нельзя проверить из-за отсутствия необходимой информации в данной единице трансляции, прилагаются все усилия, чтобы выполнить проверку во время редактирования связей. Чтобы помочь программисту в ситуации, где компилятор в компоновщик оказались бессильны, имеется механизм идентификации типов во время выполнения (см.
раздел 14.2) и исключения (см. главу 16). Предоставлять для определенных пользователем типов такую жв полноценную поддержку, как для встроенных. Поскольку определенные пользователем типы — это главное, что есть в программе на С+ь, поддержка для них должна быть максимально обширной. Поэтому ограничения типа лобъекты классов могут распределяться только в свободной памятиь признаны неприемлемыми. Необходимость в настоящих локальных переменных для таких арифметических типов, как сожр1ех, привела к тому, что поддержка для типов, имеющих значение (конкретных типов), оказалась сравнимой с поддержкой для встроенных типов, а иногда даже превосходящей ее. Локальность — это прекрасно.
Весьма желательно, чтобы написанный код был замкнутым за исключением тех случаев, когда ему нужны внешние сервисы. Хорошо, если за такими сервисами можно обрашаться без особых хлопот. И наоборот, когда функции, классы и т.п. предоставляются другим частям программы, хотелось бы не опасаться взаимодействия деталей реализации и постороннего кода.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
