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

17.5.3. Исключение глобальных статических объявлений

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

#include <header.h> namespace Mine { int a;

void f0 { /* ... */ } int go {/*...*/ }

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

tinclude <header.h> namespace { int a;

void f0 { /* ... */ } int gO { /* ... */ }

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

tinclude <header.h>

static int a;

static void f() { /* ... */ } static int gO { /* ... */ }

Обычно такая перегрузка нежелательна, но все-таки ее можно обеспечить:

namespace { tinclude <header.h> int a;

void f0 { /* ... */ } int gO { /* ... */ }

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

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

namespace { /* ... */ }

семантически эквивалентно

namespace unique name { /* ... */ } using namespace unique name;

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

17.6. Совместимость с С

Функцию с С-компоновкой можно поместить в пространство имен:

namespace X {

extern С void f(int); void g(int);

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

void h() {

X: :f О ; X::g() ;

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

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

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

namespace X {

extern С void f(int);

namespace Y {

extern C void f(int);

Проблема состоит в том, как вызвать такую функцию из программы на С. Поскольку в языке С нет механизма разрешения неоднозначности на основе пространств имен, пришлось бы полагаться на соглашение об именовании (почти наверняка зависящее от реализации). Например, программа могла бы вызывать функции X f и Y f. Такое решение было признано неприемлемым, поэтому приходится смириться с небезопасными правилами С. Язык С засоряет пространство имен компоновщика, но не глобальные пространства имен единицы трансляции С-*-+.

Обратите внимание, что это проблема С, а не пространств имен С-ы-. Связывание с программой на языке, где есть механизм, аналогичный пространствам имен в С-Ы-, реализуется простым и безопасным способом. Например, я считаю, что

namespace X {

extern Ada void f(int);

namespace Y {

extern Ada void f(int);

это естественный способ обратиться из С-ы--программы к функциям в разных пакетах языка Ada.