Неназванное пространство имен
Что это означает, когда Стандартные состояния
$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 в дополнение к анонимному пространству имен, чтобы фактически уменьшить двоичный размер.
