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

Что это означает, когда Стандартные состояния

$7.3.1.1/2 - "Использование статического ключевое слово устарело при объявлении переменные в области пространства имен (см. приложение D); пространство имен без имени обеспечивает превосходную альтернативу".

Я упомянул этот, но он не охватывает то, что я ищу.

Есть ли пример, где превосходство ясно демонстрируется.

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

Ответ 1

Что это означает?

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

На практике это не произойдет, из-за необходимости поддерживать старый код.

Таким образом, на практике это означает "сильно обескуражен".

Пример превосходства неназванного пространства имен

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

В С++ 98 внешняя связь необходима для вещей, которые могут быть параметрами шаблона, например, если вы хотите templatize на char const*, он должен быть указателем на char, который имеет внешнюю привязку.

#include <iostream>

// Compile with "-D LINKAGE=static" to see problem with "static"
#ifndef LINKAGE
#   define LINKAGE extern
#endif

template< char const* s >
void foo()
{
    std::cout << s << std::endl;
}

namespace {
    LINKAGE char const message[] = "Hello, world!";
}  // namespace anon

int main()
{
    foo<message>();
}

Тем не менее, это немного противоречиво, что static также не устаревает для функций.

Ответ 2

Это:

static int func_for_this_file_only() { ... }

"так же хорошо, как":

namespace { int func_for_this_file_only() { ... } }

но static не может использоваться для этого:

namespace { class class_for_this_file_only { ... } }

Следовательно, анонимные пространства имен на С++ более универсальны и превосходят static.

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

Ответ 3

Интересно, что ISO/IEC 14882: 2011 (С++ 11) удалил этот язык (фактически, он удаляет весь параграф §7.3.1.1/2). Он также удаляет упоминание static из Приложения D.

Таким образом, использование спецификатора класса хранения static для создания имени внутренней ссылки все еще работает (§3.5/3) и больше не устарело.

Ответ 4

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

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

Использование статики будет:

static size_t BUFSIZE = 2048; // assume not const for this example
static int myCallback( void * ptr );

Использование анонимного пространства имен

namespace {

size_t BUFSIZE = 2048;
int myCallback( void * ptr );

}

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