Д. Стефенс - C++. Сборник рецептов

// сетевые классы

}

namespace devices {

// классы устройств

}

}

Теперь доступ к элементам, содержащимся в пространстве имен, стал несколько более сложным.

// В каком-либо другом файле...

using hardware::devices::Device;

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

Псевдоним пространства имен — это то, что означает его название: имя (возможно, короткое), которое используется для замены имени (возможно, длинного) пространства имен. Если вы не хотите использовать выражение using, но также не хотите вводить при каждом использовании класса огромное полное имя, создайте для него псевдоним.

using dev = hardware::devices;

// ...

dev::Device d;

Затем этот псевдоним используется при ссылке на элементы соответствующего пространства имен.

C++ также предоставляет автоматический поиск в пространствах имен, к которым относятся параметры функций. Так, например, следующий код описывает аргументы в пространстве имен ( dev— это пространство имен, в котором объявлен Device):

void f(dev::Device& d) {

register(d); // на самом деле это dev::register

}

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

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

namespace mylib {

void foo(mt);

void foo(double);

void foo(std::string);

// Другие перегрузки foo( )...

}

// В каком-то другом файле...

using mylib::foo; // Какой вариант используется?

Объявление usingсоответствует всем перегрузкам foo, так что писать отдельную директиву для каждой перегрузки не требуется. Другим преимуществом этой записи является то, что если добавляется еще одна перегрузка foo, то весь код, содержащий объявление вида mylib::foo, видит ее автоматически (конечно, при компиляции кода, содержащего это объявление), так как объявление usingвключает и ее.

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

Как можно реже используйте using namespace xxx

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

Не используйте оператор using в заголовочных файлах

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

Не помещайте объявления using или определения перед директивами #include

Если это сделать, тогда то, что указано в директиве using, будет открыто для кода заголовочного файла, что, вероятно, не входило в намерения автора этого заголовочного файла.

При выполнении этих правил использование пространств имен в новом проекте или добавление их в существующий проект должно быть относительно просто.

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