Герб Саттер - Стандарты программирования на С++. 101 правило и рекомендация
- Название:Стандарты программирования на С++. 101 правило и рекомендация
- Автор:
- Жанр:
- Издательство:Издательский дом Вильямс
- Год:2005
- Город:Москва
- ISBN:5-8459-0859-0
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Герб Саттер - Стандарты программирования на С++. 101 правило и рекомендация краткое содержание
Эта книга поможет новичку стать профессионалом, так как в ней представлен сконцентрированный лучший опыт программистов на С++, обобщенный двумя экспертами мирового класса.
Начинающий программист найдет в ней простые и понятные рекомендации для ежедневного использования, подкрепленные примерами их конкретного применения на практике.
Опытные программисты найдут в ней советы и новые рекомендации, которые можно сразу же принять на вооружение. Программисты-профессионалы могут использовать эту книгу как основу для разработки собственных стандартов кодирования, как для себя лично, так и для группы, которой они руководят.
Конечно, книга рассчитана в первую очередь на профессиональных программистов с глубокими знаниями языка, однако она будет полезна любому, кто захочет углубить свои знания в данной области.
Стандарты программирования на С++. 101 правило и рекомендация - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
Все функции, являющиеся точками входа в модуль, непосредственно отвечают за преобразование между внутренней и внешней стратегиями, если они различны. Например, в модуле, который внутренне использует исключения С++, но предоставляет интерфейс в стиле С API, все функции интерфейса должны содержать перехват catch(...)
всех исключений и преобразовывать их в коды ошибок.
Обратите внимание, в частности, на то, что функции обратного вызова и функции потоков по определению являются (или могут быть) границами модуля. Тело каждой функции обратного вызова или функции потока должно преобразовывать внутренний механизм ошибок в механизм, использующийся стратегией интерфейса (см. рекомендацию 62).
[Abrahams01b] • [Allison98] §13 • [McConnell93] §5.6 • [Stroustrup94] §16.2, §E.2 • [Stroustrup00] §14.9, §19.3.1 • [Sutter04b]
70. Отличайте ошибки от ситуаций, не являющихся ошибками
Функция представляет собой единицу работы. Таким образом, сбои следует рассматривать либо как ошибки, либо как штатные ситуации, в зависимости от их влияния на функции. В функции f
сбой является ошибкой тогда и только тогда, когда он нарушает одно из предусловий f
, не позволяет выполнить предусловие вызываемой ею функции, препятствует достижению собственных постусловий f
или сохранению инварианта, за поддержку которого отвечает функция f
.
В частности, в этой рекомендации мы исключаем внутренние программные ошибки (т.е. те, где за вызывающий и вызываемый код отвечает один и тот же человек или команда, например, в пределах одного модуля). Они представляют собой отдельную категорию ошибок, для работы с которой используется такое средство, как проверки (см. рекомендацию 68).
Очень важно четко различать ошибки и ситуации, не являющиеся ошибками в плане их влияния на работу функций, в особенности в целях определения гарантий безопасности (см. рекомендацию 71). Ключевыми словами данной рекомендации являются предусловие, постусловие и инвариант.
Функция представляет собой базовую единицу работы, независимо от того, программируете ли вы на С++ в структурном, объектно-ориентированном или обобщенном стиле. Функция делает определенные предположения о начальном состоянии (предусловия, за выполнение которых несет ответственность вызывающий код, а за проверку — вызываемый) и выполняет одно или несколько действий (документируемых, как результат выполнения функции, или ее постусловия, за выполнение которых несет ответственность данная функция). Функция может (наряду с другими функциями) нести ответственность за поддержание одного или нескольких инвариантов. В частности, не закрытая неконстантная функция-член по определению представляет собой единицу работы над объектом, и должна перевести объект из одного корректного, сохраняющего инвариант состояния в другое. Во время выполнения тела функции-члена инвариант объекта может (и практически всегда должен) нарушаться, и это вполне нормальная ситуация, лишь бы по окончании работы функции-члена инвариант вновь выполнялся. Функции более высокого уровня объединяют функции более низкого уровня в большие единицы работы.
Ошибкой является любой сбой, который не дает функции успешно завершиться. Имеется три вида ошибок.
• Нарушение или невозможность достижения предусловия. Функция обнаруживает нарушение одного из своих собственных предусловий (например, ограничения, накладываемого на параметр или состояние) или сталкивается с условием, которое не позволяет достичь выполнения предусловия для некоторой другой неотъемлемой функции, которая должна быть вызвана.
• Неспособность достичь постусловия. Функция сталкивается с ситуацией, которая не позволяет ей выполнить одно из ее собственных постусловий. Если функция возвращает значение, получение корректного возвращаемого значения является ее постусловием.
• Неспособность восстановления инварианта. Функция сталкивается с ситуацией, которая не позволяет ей восстановить инвариант, за поддержку которого она отвечает. Это частный случай постусловия, который в особенности относится к функциям- членам. Важнейшим постусловием всех не закрытых функций-членов является восстановление инварианта класса (см. [Stroustrup00] §E.2.)
Все прочие ситуации ошибками не являются, и, следовательно, уведомлять о них, как об ошибках, не требуется (см. примеры к данной рекомендации).
Код, который может вызвать ошибку, отвечает за ее обнаружение и уведомление о ней. В частности, вызывающий код должен обнаружить и уведомить о ситуации, когда он не в состоянии выполнить предусловия вызываемой функции (в особенности если для вызываемой функции документировано отсутствие проверок с ее стороны; так, например, оператор vector::operator[]
не обязан выполнять проверку попадания аргумента в корректный интервал значений). Однако поскольку вызываемая функция не может полагаться на корректность работы вызывающего кода, желательно, чтобы она выполняла собственные проверки предусловий и уведомляла об обнаруженных нарушениях, генерируя ошибку (или, если функция является внутренней для (т.е. вызываемой только в пределах) модуля, то нарушение предусловий по определению является программной ошибкой и должно обрабатываться при помощи assert
(см. рекомендацию 68)).
Добавим пару слов об определении предусловий функций. Условие является предусловием функции f
тогда и только тогда, когда имеются основания ожидать, что весь вызывающий код проверяет выполнение данного условия перед вызовом функции f
. Например, было бы неверно полагать предусловием нечто, что может быть проверено только путем выполнения существенной работы самой функцией, либо путем доступа к закрытой информации. Такая работа должна выполняться в функции и не дублироваться вызывающим ее кодом.
Например, функция, которая получает объект string
, содержащий имя файла, обычно не должна делать условие существования файла предусловием, поскольку вызывающий код не в состоянии надежно гарантировать, что данный файл существует, не используя блокировки файла (при проверке существования файла без блокировки другой пользователь или процесс могут удалить или переименовать этот файл в промежутке между проверкой существования файла вызывающим кодом и попыткой открытия вызываемым кодом). Единственный корректный способ сделать существование файла предусловием — это потребовать, чтобы вызывающий код открыл его, а параметром функции сделать ifstream
или его эквивалент (что к тому же безопаснее, поскольку работа при этом выполняется на более высоком уровне абстракции; см. рекомендацию 63), а не простое имя файла в виде объекта string
. Многие предусловия таким образом могут быть заменены более строгим типизированием, которое превратит ошибки времени выполнения в ошибки времени компиляции (см. рекомендацию 14).
Интервал:
Закладка: