Б. Страуструп - Дизайн и Эволюция C++. 2006 (1160775), страница 31

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 31)

Большинство возможностей удалось реализовать, проверить и подвергнуть окончательной Общие правила ревизии. Там, где не соблюдалась такая схема, например в случае с механизмом и~- стаицирования шаблонов (см. раздел 15.10), возникали неприятности. Однако пользователей гораздо больше, чем разработчиков компиляторов. Поэтому всякий раз, когда приходится выбирать между сложностью компилятора и примеиеиия, решение должно приниматься в интересах пользователей. Я заслужил право на такое мнение, поскольку в течение многих лет сам занимался сопровождением компилятора. Всегда оппавлять путь для перехода.

С-н. должен развиваться постепенно, чтобы обслуживать потребности своих пользователей. Также нельзя обойтись и без обратной связи с сообществом. Значит, необходимо внимательно следить за тем, чтобы ранее написанный код продолжал работать. Если несовместимости не избежаты то надо приложить все усилия, чтобы помочь пользователям модернизировать свои программы. Точно так же следует указать путь перехода от неудачных приемов программирования иа С к более результативному использованию С++.

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

Эту стратегию можно поддержать с помощью предупреждений компилятора. Часто ие представляется возможным отказаться от некоторого средства или исправить ошибку (причина, как правило, в необходимости сохранять совместимость с С); тогда остаются только предупреждения (см. раздел 2.6.2). Таким образом, реализация С++ может оказаться более безопасной, чем следует из определения языка. С++ — это язык, а не закончеяная сисглема. Среда программирования состоит из многих компонентов. Можно объединить их в единую — интегрированную— систему.

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

Это ключ к переносимости реализации и, что важнее, к возможности обращаться к коду, написанному на других языках. Это также позволяет пользоваться общими инструментами, облегчает совместную работу программистов, предпочитающих разные языки, и дает возможность одному человеку работать на разных языках. По своему замыслу С++ — зто лишь олин язык среди многих. Ои позволяет разрабатывать ииструментальные средства, но не требует никаких конкретных форм. У программиста остается свобода выбора. С++ и сопутствующий инструментарий должны хорошо вписываться в даииую систему. Особенно важно это для больших систем и систем с необычными ограничениями. Такие системы, как правило, ие очень хорошо поддерживаются, поскольку «стандартные» инструментальные средства ориентированы преимущественно на отдельных программистов и небольшие коллективы, выполняющие «среднюю» работу.

ИИИИИИИ61 Правила проектирования языка С++ Предоставлять всестороннюю поддержку длл каждого поддерживаемого стиля программирования. С~-~ должен развиваться, чтобы не отставать от потребностей серьезных программистов. Простота, конечно, важна, но нужно принимать во внимание и сложность проектов, в которых используется С++. Удобство сопровождения системы, написанной на С++, и ее производительность считаются более важными, нежели краткость определения языка. В результате язык получается довольно сложным.

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

Нередки и программы, части которых написаны в разных стилях, отражающих вкусы и потребности автора. Следовательно, языковые средства нужно проектировать так, чтобы их можно было применять в разных сочетаниях. Отсюда вытекает некоторая ортогональность проектирования С++, Возможность «необычного» использования — важный источник гибкости, заложенной в С++. Так, в атом языке правила контроля доступа, поиска подходящего имени, привязки виртуальных и невиртуальных функций и проверки типов ортогональны.

Это делает возможным применение различных приемов, опирающихся на сокрытие информации и наследование классов. Пользователи, предпочитающие видеть лишь жестко определенные стили программирования, называют зто «хакерством». С другой стороны, ортогональность не относится к числу первостепенных принципов языка. С++ — развитый язык, и из етого следует, что программисту придется не только изучить библиотеки и отдельные программы, но и освоить язык и базовые приемы его использования для проектирования. Для большинства пользователей такое смещение акцентов, привыкание к новым методам программирования и включение в свой арсенал прогрессивных средств должно быть постепенным. Лишь немногие могут усвоить все сразу и применить вновь приобретенные навыки на практике (см.

раздел 7.2). С++ спроектирован так, чтобы постепенное освоение было возможным и естественным. Общий принцип таков; если не анаешь, то и не страдаешь. Статическая система контроля типов и предупреждения компилятора всегда помогут. Ничего нв заставлять делать насильно. Программисты — толковые ребята. Перед ними ставятся непростые задачи, поэтому им пригодится все, что можно получить от языка программирования и сопутствующих инструментальных средств. Попытка ограничить пользователя, заставив его «делать правильно», заведомо бессмысленна и обречена на провал. Программист найдет способ обойти ограничение, которое считает неприемлемым.

Следовательно, язык должен поддерживать широкий диапазон разумных стилей проектирования и программирования, а не навязывать единую концепцию. Вышесказанное не означает, что все способы программирования равно хороши или что С++ должен поддерживать любой имеющийся стиль. С++ проектировался для прямой поддержки стилей проектирования, базирующихся на статическом контроле типов, абстрагировании данных и наследовании. Однако Правила поддержки проектирования НИИИИИЮ наставления на тему о том, как правильно использовать эти средства, сведены к минимуму, и никакие средства не добавлялись в язык и не исключались из него только ради того, чтобы воспрепятствовать некоему логически последовательному стилю программирования. Я хорошо знаю, что далеко не все ценят свободу выбора и разнообразие.

Однако те, кто предпочитает более ограниченную среду, вольны наложить на С++ собственные правила или выбрать язык, предоставляющий программисту меньший выбор. Многим программистам не нравится, когда им говорят, что «вот тут возможна ошибка», если они точно знают, что ошибки здесь быть не может. Поэтому «потенциальные ошибки» в С++ таковыми не являются. Например, не считается ошибкой объявление, в принципе допускающее неоднозначное использование. Ошибкой будет само неоднозначное использование, а не его возможность. Мой опыт показывает, что такие «потенциальные ошибки» никогда не проявляются, поэтому откладывание диагностического сообщения обычно означает, что оно так и не будет выдано. Это приносит дополнительное удобство и гибкость.

4.3. Правила поддержки проектирования Перечисленные в таблице 4.3 правила относятся главным образом к роли С+а как инструмента поддержки проектирования на основе абстрагирования данных и объектно-ориентированного программирования. Иными словами, язык в них рассматривается, скорее, как средство организации процесса мышления и выражения идей на достаточно высоком уровне, нежели как «высокоуровневый ассемблер», что характерно для С или Разсай Таблица 4.3 Правила поддержки проектирования Повдерживать устоявшиеся методы проектирования Предоставлять средства для организации программ Точно говорить то, что имеется в виду Все воэможности должны быть адекватны Важнее включить полезную воэможность, чем предотвращать неправильное использование Поддерживать сборку программ из независимо разработанных частей Поддерживать устоявшиеся методы проектирования.

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

Моей целью было поднять уровень абстракции в системном программировании. Точно так же С заменил ассемблер в роли главной опоры системщика. Все ПИИИИИИ61 Правила проектирования языка С++ идеи по поводу новых возможностей рассматриваются в свете того, как они помогают улучшить выразительность языка для описания проектирования. В частности, способствуют ли они более зффектив ному представлению концепции в виде класса? Это ключ к тому, как в С++ поддерживаются абстракции данных и объектноориентированное программирование.

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

Характеристики

Список файлов книги