Стандарты программирования на С++ - читать бесплатно онлайн полную версию книги автора Герб Саттер (Пространства имен и модули) #8

Пространства имен и модули

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

— Алан Перлис (Alan Perlis)

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

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

В этом разделе мы считаем наиболее значимой рекомендацию 58 — "Храните типы и функции в разных пространствах имен, если только они не предназначены для совместной работы".

57. Храните типы и их свободный интерфейс в одном пространстве имен

Резюме

Функции, не являющиеся членами и разработанные как часть интерфейса класса

(в особенности операторы и вспомогательные функции), должны быть определены в том же пространстве имен, что и

, что обеспечивает их корректный вызов.

Обсуждение

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

все функции (включая функции, не являющиеся членами), которые "упоминают

" и "поставляются вместе с

" в одном и том же пространстве имен, являются логической частью

, поскольку образуют часть интерфейса

(см. рекомендацию 44 и [Sutter00]).

Язык С++ спроектирован с явным учетом Принципа Интерфейса. Причина, по которой в язык добавлен поиск, зависящий от аргумента (argument-dependent lookup — ADL), известный также как поиск Кёнига, заключается в том, чтобы обеспечить коду, использующему объект

типа

, возможность работать с частью его интерфейса, состоящей из функций, не являющихся членами (например, инструкция

cout << x

использует оператор

operator<<

, который не является членом класса

) так же легко, как и функции-члены (например, вызов

x.f()

) не требует выполнения специального поиска, поскольку очевидно, что поиск

выполняется в области видимости

). ADL обеспечивает для свободных функций, которые получают объект

в качестве аргумента и поставляются вместе с определением

ту же простоту использования, что и для функций-членов интерфейса

. Одним из главных мотивов принятия ADL был, в частности, класс

std::string

(см. [Sutter00]).

Рассмотрим класс

, определенный в пространстве имен N:

class X {

publiс:

 void f();

};

X operator+(const X&, const X&);

В вызывающей функции обычно пишется код наподобие

x3=x1+x2

, где

x1

x2

x3

— объекты типа

. Если оператор

operator+

объявлен в том же пространстве имен, что и

, никаких проблем не возникает, и такой код отлично работает, поскольку оператор

operator+

будет легко найден с помощью ADL.

Если же оператор

operator+

не объявлен в том же пространстве имен, что и

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

x3 = N::operator+(x1, x2);

Грустная картина — невозможность использовать естественный синтаксис оператора, который, собственно, и был главной целью введения перегрузки операторов в язык программирования. Другой способ заставить работать приведенный ранее код — использовать инструкцию

using

using N::operator+;

// или: using namespace N;

x3 = x1 + x2;

Применение

using

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

изначально поступает корректно и помещает оператор

operator+

, работающий с объектами

, в то же пространство имен, где находится

"Оборотная сторона" этого вопроса рассматривается в рекомендации 58.

Примеры

Пример 1. Операторы. Операторы работы с потоками

operator<<

operator>>

для объектов некоторого класса

, вероятно, относятся к наиболее ярким примерам функций, которые вполне очевидно являются частью интерфейса класса

, но при этом всегда представляют собой свободные функции (это обязательное условие, поскольку левый аргумент этих операторов — поток, а не объект

). Та же аргументация применима и к другим операторам, не являющимся членами

. Убедитесь, что ваши операторы находятся в том же пространстве имен, что и класс, с которым они работают. Если у вас есть возможность выбора, лучше делать операторы и все прочие функции не членами и не друзьями класса (см. рекомендацию 44).

Пример 2. Прочие функции. Если автор

предоставляет именованные вспомогательные функции, которые получают в качестве аргументов объекты

, они должны находиться в том же пространстве имен, что и

. В противном случае вызывающий код, использующий объекты

, будет не в состоянии работать с этими именованными функциями без явной квалификации их имен или применения инструкции

using

Ссылки

[Stroustrup00] §8.2, §10.3.2, §11.2.4 • [Sutter00] §31-34

58. Храните типы и функции в разных пространствах имен, если только они не предназначены для совместной работы

Резюме

Оберегайте ваши типы от непреднамеренного поиска, зависящего от аргументов (argument-dependent lookup — ADL, известный также как поиск Кёнига); однако преднамеренный поиск должен завершаться успешно. Этого можно добиться путем размещения типов в своих собственных пространствах имен (вместе с непосредственно связанными с ними свободными функциями; см. рекомендацию 57). Избегайте помещения типов в те же пространства имен, что и шаблоны функций или операторов).

Обсуждение

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

Вот реальный пример, который был опубликован в группе новостей:

#include

namespace N {

struct X { };

template

int* operator+(T , unsigned) {/* некоторые действия */}

int main() {

 std::vector v(5);

 v[0];

Инструкция

v[0];

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

vector::operator[]

спрятан код наподобие

v.begin()+n

, и поиск имен для функции

operator+

может достичь пространства имен (в нашем случае

) типа, для которого инстанцирован вектор (в нашем случае

). Достигнет ли поиск этого пространства имен или нет — зависит от того, как определен

vector::iterator

в данной версии реализации стандартной библиотеки. Однако если поиск достигает

, то здесь он находит

N::operator+

. Наконец, в зависимости от используемых типов, компилятор может просто посчитать, что для

vector::iterator

оператор

N::operator+

имеет лучшее соответствие, чем оператор

std::operator+

из реализации стандартной библиотеки (который и должен был быть вызван). (Один из способов избежать такой неприятности в реализации стандартной библиотеки — не использовать код

v.begin()+n

таким образом, что он вносит непреднамеренную точку настройки: либо надо изменить код так, чтобы тип

v.begin()

никаким образом не зависел от параметра шаблона, либо вызов

operator+

следует переписать с указанием полного квалифицированного имени. См. рекомендацию 65.)

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

N::operator+

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

Вы думаете, что вам не приходилось с этим сталкиваться? Попробуйте вспомнить, бывало ли такое в вашей практике, что ваш код, например, с использованием стандартной библиотеки приводил к удивительным и непонятным ошибкам компиляции? А после того как вы слегка меняли ваш код, порой просто меняя местами отдельные куски кода, все вдруг начинало работать и у вас оставалось только небольшое недоумение по поводу глупого компилятора, который запутался в трех строках? Практически все мы попадали в подобные ситуации, когда причиной неприятностей становилась рассматриваемая проблема, т.е. когда ADL находил имена из неподходящего пространства имен просто потому, что типы из этих пространств имен использовались поблизости друг от друга.

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

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

, в том же пространстве имен, где находится

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

Примечание. Да, стандартная библиотека С++ помещает алгоритмы и другие шаблоны функций, таких как

copy

или

distance

, в то же пространство имен, что и множество типов, таких как

pair

или

vector

. Все они находятся в одном пространстве имен. Это неудачное решение, которое вызывает описанные весьма тонкие и трудно локализуемые проблемы. К счастью, теперь у нас больше опыта и мы знаем, как следует поступать. Не делайте так, как сделано в стандартной библиотеке.

"Оборотная сторона" этого вопроса рассматривается в рекомендации 57.

Ссылки

[Stroustrup00] §10.3.2, §11.2.4 • [Sutter00] §34 • [Sutter02] §39-40

59. Не используйте

using

для пространств имен в заголовочных файлах или перед директивой

#include

Резюме

Директива

using

для пространств имен создана для вашего удобства, а не для головной боли других. Никогда не используйте объявления или директивы

using

перед директивой

#include

Вывод: не используйте директивы

using

для пространств имен или

using

-объявления в заголовочных файлах. Вместо этого полностью квалифицируйте все имена. (Второе правило следует из первого, поскольку заголовочные файлы не могут знать, какие другие директивы

#include

могут появиться в тексте после них.)

Обсуждение

Вкратце: вы можете и должны свободно и без ограничений использовать объявления и директивы

using

в своих файлах реализации после директив

#include

. Несмотря на повторяющиеся заявления их противников, объявления и директивы

using

не являются злом и не противоречат цели пространств имен. Они просто делают пространства имен более удобными в использовании.

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

using

, которые существенно облегчают использование пространств имен, снижая количество вводимого кода (программисту при использовании директив и объявлений

using

не требуется всякий раз явное упоминание того, к какому пространству имен принадлежит то или иное имя). В редких случаях коллизий имен директивы и объявления

using

не препятствуют указанию полностью квалифицированных имен для разрешения реально возникшей неоднозначности.

Однако директивы и объявления

using

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

#include

(тем самым вы по сути вносите их в текст этих заголовочных файлов).

Большинство программистов интуитивно понимают, почему директива

using

(например,

using namespace A;

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

Но вот одна распространенная ошибка: многие считают, что использование объявления

using

на уровне пространства имен (например,

using N::Widget;

) вполне безопасно. Однако это не так. Такие объявления, как минимум, опасны, причем более тонким и хитрым способом. Рассмотрим следующий код:

// Фрагмент 1

namespace A {

 int f(double);

// Фрагмент 2

namespace B {

 using A::f;

 void g();

// Фрагмент 3

namespace A {

 int f(int);

// Фрагмент 4

void В::g() {

 f(1); // какая перегрузка будет вызвана?

Здесь опасность заключается в том, что объявление

using

использует текущий список имен

в пространстве имен

А

в тот момент, когда это объявление встречается. Таким образом, какая именно перегрузка будет видима в пространстве имен

В

, зависит от того, где именно находится приведенный код фрагментов и в каком порядке он скомбинирован. (Здесь должен раздаться предупреждающий рев вашей внутренней сирены — "Зависимость от порядка есть зло!") Вторая перегрузка,

f(int)

, в большей степени соответствует вызову

f(1)

, но

f(int)

будет невидима для

B::g

, если ее объявление окажется после объявления

using

Рассмотрим два частных случая. Пусть фрагменты 1, 2 и 3 находятся в трех различных заголовочных файлах

s1.h

s2.h

s3.h

, а фрагмент 4 — в файле реализации

s4.срр

, который включает указанные заголовочные файлы. Тогда семантика

B::g

зависит от порядка, в котором заголовочные файлы включены в

s4.срр

! В частности:

• если

s3.h

идет перед

s2.h

, то

B::g

будет вызывать

A::f(int)

;

• иначе если

s1.h

идет перед

s2.h

, то

B::g

будет вызывать

A::f(doublе)

;

• иначе

B::g

не будет компилироваться вовсе.

В описанной ситуации имеется один вполне определенный порядок, при котором все работает так, как должно.

Давайте теперь рассмотрим ситуацию, когда фрагменты 1, 2, 3 и 4 находятся в четырех различных заголовочных файлах

s1.h

s2.h

s3.h

s4.h

. Теперь все становится существенно хуже: семантика

B::g

зависит от порядка включения заголовочных файлов не только в

s4.h

, но и в любой код, который включает

s4.h

! В частности, файл реализации

client_code.срр

может пытаться включить заголовочные файлы в любом порядке:

• если

s3.h

идет перед

s2.h

, то

B::g

будет вызывать

A::f(int)

;

• иначе если

s1.h

идет перед

s2.h

, то

B::g

будет вызывать

A::f(doublе)

;

• иначе

B::g

не будет компилироваться вовсе.

Ситуация стала хуже потому, что два файла реализации могут включать заголовочные файлы в разном порядке. Что произойдет, если

client_code_1.срр

включает

s1.h

s2.h

s4.h

в указанном порядке, a

client_code_2.срр

включает в соответствующем порядке

s3.h

s2.h

s4.h

? Тогда

B::g

нарушает правило одного определения (one definition rule — ODR), поскольку имеются две несогласующиеся несовместимые реализации, которые не могут быть верными одновременно: одна из них пытается вызвать

A::f(int)

, а вторая —

A::f(doublе)

Поэтому никогда не используйте директивы и объявления

using

для пространств имен в заголовочных файлах либо перед директивой

#include

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

using

кода, например, вследствие загрязнения пространства имен или неполного списка импортируемых имен. (Обратите внимание на "директивы и объявления

using

для пространств имен". Указанное правило неприменимо при описании члена класса с помощью объявления

using

для внесения, при необходимости, имен из базового класса.)

Во всех заголовочных файлах, как и в файлах реализации до последней директивы

#include

, всегда используйте явные полностью квалифицированные имена. В файлах реализации после всех директив

#include

вы можете и должны свободно использовать директивы и объявления

using

. Это верный способ сочетания краткости кода с модульностью.

Исключения

Перенесение большого проекта со старой до-ANSI/ISO реализации стандартной библиотеки (все имена которой находятся в глобальном пространстве имен) к использованию новой (где практически все имена находятся в пространстве имен

std

) может заставить вас аккуратно разместить директиву

using

в заголовочном файле. Этот способ описан в [Sutter02].

Ссылки

[Stroustrup00] §9.2.1 • [Sutter02] §39-40

60. Избегайте выделения и освобождения памяти в разных модулях

Резюме

Золотое правило программиста — положи, где взял. Выделение памяти в одном модуле, а освобождение в другом делает программу более хрупкой, создавая тонкую дальнюю зависимость между этими модулями. Такие модули должны быть компилируемы одной и той же версией компилятора с одними и теми же флагами (в частности, отладочные версии и версии

NDEBUG

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

Обсуждение

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

Следовательно, о функции освобождения памяти (т.е. операторе

::operator delete

или функции

std::free

) при пересечении границ модулей практически нельзя строить какие-либо предположения, в особенности при пересечении границ модулей, при котором вы не можете гарантировать, что они будут скомпилированы одним и тем же компилятором С++ с одними и теми же опциями. Конечно, часто эти модули находятся в одном и том же файле проекта и компилируются с одними и теми же опциями, но комфорт часто приводит к забывчивости. В особенности высока цена такой забывчивости при переходе к динамически связываемым библиотекам, распределении большого проекта между несколькими группами или при замене модулей "на ходу" — в этом случае вы должны уделить максимум внимания тому, чтобы выделение и освобождение памяти выполнялось в пределах одного модуля или подсистемы.

Хорошим методом обеспечения освобождения памяти соответствующей функцией является использование

shared_ptr

(см. [C++TR104]). Интеллектуальный указатель

shared_ptr

со счетчиком ссылок может захватить свой "удалитель" в процессе конструирования. "Удалитель" — это функциональный объект (или обычный указатель на функцию), который выполняет освобождение памяти. Поскольку упомянутый функциональный объект, или указатель на функцию, является частью состояния объекта

shared_ptr

, модуль, выделивший память объекту, может одновременно определить функцию освобождения памяти, и эта функция будет корректно вызвана, даже если точка освобождения находится где-то в другом модуле — вероятно, относительно небольшой ценой (корректность важнее цены; см. также рекомендации 5, 6 и 8). Конечно, исходный модуль при этом должен оставаться загруженным.

Ссылки

[С++TR104]

61. Не определяйте в заголовочном файле объекты со связыванием

Резюме

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

Обсуждение

Когда мы начинаем использовать С++, то все достаточно быстро уясняем, что заголовочный файл наподобие

// Избегайте определения объектов с внешним

// связыванием в заголовочном файле

int fudgeFactor;

string hello("hello, world!");

void foo() { /* ... */ }

будучи включен больше чем в один исходный файл, ведет при компиляции к ошибкам дублирования символов во время компоновки. Причина проста: каждый исходный файл в действительности определяет и выделяет пространство для

fudgeFactor

hello

и тела

foo

, и когда приходит время сборки (компоновки, или связывания), компоновщик сталкивается с наличием нескольких объектов, которые носят одно и то же имя и борются между собой за видимость. Решение проблемы простое — в заголовочный файл надо поместить только объявления:

extern int fudgeFactor;

extern string hello;

void foo(); // В случае объявления функции "extern"

      // является необязательным

Реальные же объявления располагаются в одном файле реализации:

int fudgeFactor;

string hello("hello, world!");

void foo() { /* ... */ }

He определяйте в заголовочном файле и статические объекты уровня пространства имен, например:

// избегайте определения объектов со статическим

// связыванием в заголовочном файле

static int fudgeFactor;

static string hello("Hello, world!");

static void foo() { /* ... */ }

Такое некорректное использование ключевого слова

static

более опасно, чем простое определение глобальных объектов в заголовочном файле. В случае глобальных объектов, по крайней мере, компоновщик в состоянии обнаружить наличие дублей. Но статические данные и функции могут дублироваться на законных основаниях, поскольку компилятор делает закрытую копию для каждого исходного файла. Так что если вы определите статические данные и статические функции в заголовочном файле и включите его в 50 файлов, то тела функций и пространство для данных в выходном исполняемом файле будут дублированы 50 раз (только если у вас не будет использован очень интеллектуальный компоновщик, который сможет распознать 50 одинаковых тел функций и наличие одинаковых константных данных, которые можно безопасно объединить). Излишне говорить, что глобальные данные (такие как статические

fudgeFactor

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

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

// В заголовочном файле это приводит к тому же

// эффекту, что и использование static

namespace {

int fudgeFactor;

string hello("Hello, world!");

void foo() { /* ... */ }

Исключения

В заголовочных файлах могут находиться следующие объекты с внешним связыванием.

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

• Шаблоны функций. Аналогично встраиваемым функциям, инстанцирования ведут себя так же, как и обычные функции, с тем отличием, что их дубликаты приемлемы (и должны быть идентичны). Само собой разумеется, хороший компилятор устранит излишние копии.

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

Кроме того, методика инициализации глобальных данных, известная как "Счетчики Шварца" ("Schwarz counters"), предписывает использование в заголовочном файле статических данных (или безымянных пространств имен). Джерри Шварц (Jerry Schwarz) использовал эту методику для инициализации стандартных потоков ввода-вывода

cin

cout

cerr

clog

, что и сделало ее достаточно популярной.

Ссылки

[Dewhurst03] §55 • [Ellis90] §3.3 • [Stroustrup00] §9.2, §9.4.1

62. Не позволяйте исключениям пересекать границы модулей

Резюме

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

Обсуждение

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

Как минимум, ваше приложение должно обеспечить наличие заглушек

catch(...)

в перечисленных ниже местах, большинство из которых непосредственно связаны с модулями.

• Вокруг

main

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

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

• Вокруг границ потока. В конечном итоге поток выполнения создается внутри операционной системы. Убедитесь, что ваша функция, представляющая поток, не преподнесет операционной системе сюрприз в виде исключения.

• Вокруг границ интерфейса модуля. Ваша подсистема предоставляет окружающему миру некоторый открытый интерфейс. Если подсистема представляет собой отдельную библиотеку, лучше, чтобы исключения оставались в ее границах, а для сообщения об ошибках использовались старые добрые коды ошибок (см. рекомендацию 72).

• Внутри деструкторов. Деструкторы не должны генерировать исключений (см. рекомендацию 51). Деструкторы, которые вызывают функции, способные генерировать исключения, должны защититься от возможной утечки этих исключений.

Убедитесь, что каждый модуль согласованно использует одну и ту же внутреннюю стратегию обработки ошибок (предпочтительно — исключения С++; см. рекомендацию 72) и единую стратегию обработки ошибок в интерфейсе (например, коды ошибок для API на языке С); обе эти стратегии могут быть одинаковы, но обычно это не так. Стратегии обработки ошибок могут изменяться только на границах модуля. Определите, как происходит связывание стратегий между модулями (например, как происходит взаимодействие с COM или CORBA, или что всегда следует перехватывать исключения на границе с API на языке С). Хорошим решением будет определить центральные функции, которые выполняют преобразования между исключениями и кодами ошибок, возвращаемых подсистемой. Так вы сможете легко транслировать входящие ошибки от других модулей в используемые внутренние исключения и тем самым упростить интеграцию.

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

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

catch(...)

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

catch(...)

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

catch(...)

последовательностью перехватов

catch(E1&){/*...*/} catch(E2&){/*.. .*/} ... catch(En&){/*...*/}

для всех известных типов базовых исключений

Ei

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

Использование

catch(...)

в других, не перечисленных в данной рекомендации местах зачастую является признаком плохого проектирования, поскольку означает, что вы хотите перехватить абсолютно все исключения без обязательного знания о том, как следует обрабатывать конкретные исключения (см. рекомендацию 74). В хорошей программе не так много перехватов всех исключений, да и вообще инструкций try/catch; в идеале ошибки распространяются через весь модуль, транслируются на его границе (неизбежное зло) и обрабатываются в стратегически размещенных местах.

Ссылки

[Stroustrup00] §3.7.2, §14.7 • [Sutter00] §8-17 • [Sutter02] §17-23 • [Sutter04] §11-13

63. Используйте достаточно переносимые типы в интерфейсах модулей

Резюме

Не позволяйте типам появляться во внешнем интерфейсе модуля, если только вы не уверены в том, что все пользователи смогут корректно их понять и работать с ними. Используйте наивысший уровень абстракции, который в состоянии понять клиентский код.

Обсуждение

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

int

char

. Даже один и тот же тип на одном и том же компиляторе может оказаться бинарно несовместимым при компиляции с разными опциями.

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

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

SummarizeFile

, которая получает в качестве аргумента файл. Имеется три варианта действий — передать указатель

char*

на строку в стиле С с именем файла; передать

string

с именем файла и передать объект

istream

или пользовательский объект

Filе

. Каждый из этих вариантов представляет свой уровень компромисса.

• Вариант 1.

char*

. Очевидно, что тип

char*

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

• Вариант 2.

string

. Тип

string

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

string

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

• Вариант 3.

istream

или

File

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

istream

(или пользовательский класс

File

, представляющий собой оболочку вокруг

istream

, позволяющую устранить зависимость от реализации стандартной библиотеки) повышает уровень абстракции и делает API существенно менее проблематичным. Функция получает объект типа

File

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

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

void*

или дескриптором типа

int

для работы с клиентом, но во внутренней реализации используйте высокоуровневые объекты. Преобразование между этими объектами и выбранными низкоуровневыми типами выполняйте только в интерфейсе модуля.

Примеры

Пример. Использование

std::string

в интерфейсе модуля. Пусть мы хотим, чтобы модуль предоставлял следующую функцию API:

std::string Translate(const std::string&);

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

std::string

(например, иное размещение в памяти), то из-за такого несоответствия могут случиться разные странные и неприятные вещи.

Мы встречались с разработчиками, которые пытались использовать собственный класс-оболочку

CustomString

для объектов

std::string

, но в результате они сталкивались с той же проблемой, поскольку не имели полного контроля над процессом сборки всех клиентских приложений.

Одно из решений состоит в переходе к переносимым (вероятно, встроенным) типам, как вместо функции с аргументом

string

, так и в дополнение к ней. Такой новой функцией может быть функция

void Translate(const char* src, char* dest, size_t destSize);

Использование низкоуровневой абстракции более переносимо, но всегда добавляет сложности; здесь, например, как вызывающий, так и вызываемый код должны явно использовать обрезку строки, если размера буфера оказывается недостаточно. (Заметим, что данная версия использует буфер, выделяемый вызывающим кодом, для того чтобы избежать ловушки, связанной с выделением и освобождением памяти в разных модулях — см. рекомендацию 60.)

Ссылки

[McConnell93] §6 • [Meyers01] §15