безымянное пространство имен - PullRequest
14 голосов
/ 18 ноября 2010

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

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

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

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

NB. Я знаю о том, как безымянные пространства имен могут сделать внешние переменные видимыми в модуле перевода, но скрыть их от других модулей перевода. Но суть этого поста - в именах «области статического пространства имен» (например, глобальные статические переменные)

Ответы [ 4 ]

11 голосов
/ 18 ноября 2010

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

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

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

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

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

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

В C ++ 98 внешняя связь необходима для вещей, которые могут быть параметрами шаблона, например, если вы хотите шаблонизировать 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 также не рекомендуется для функций.

10 голосов
/ 18 ноября 2010

Это:

static int func_for_this_file_only() { ... }

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

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

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

namespace { class class_for_this_file_only { ... } }

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

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

6 голосов
/ 20 июля 2013

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

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

2 голосов
/ 18 ноября 2010

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

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

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

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 в дополнение к анонимному пространству имен для фактического уменьшения двоичного размера.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...