Безымянное / анонимное пространство имен против статических функций

Особенностью C ++ является возможность создавать безымянные (анонимные) пространства имен, например:

namespace {
    int cannotAccessOutsideThisFile() { ... }
} // namespace

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

Мой вопрос: почему или когда это было бы предпочтительнее использования статических функций? Или это по сути два способа сделать одно и то же?

Стандарт C ++ гласит в разделе 7.3.1.1 Безымянные пространства имен, параграф 2:

Использование статического ключевого слова не рекомендуется при объявлении объектов в области пространства имен. Пространство без имени обеспечивает превосходную альтернативу.

Статика применяется только к именам объектов, функций и анонимных объединений, но не к объявлениям типов.

Редактировать:

Решение об отказе от использования этого ключевого слова static (влияет на видимость объявления переменной в модуле перевода) было отменено ( ссылка ). В этом случае использование статического или безымянного пространства имен вернулось к тому, чтобы быть по сути двумя способами сделать одно и то же. Для дальнейшего обсуждения, пожалуйста, смотрите этот вопрос.

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

Кредит идет Майку Перси за то, что он обратил на это мое внимание.

Помещение методов в анонимное пространство имен предотвращает случайное нарушение правила One Definition , позволяя вам никогда не беспокоиться о присвоении имен вашим вспомогательным методам так же, как и другим методам, на которые вы можете ссылаться.

И, как указал luke, анонимные пространства имен предпочитаются стандартом над статическими членами.

Есть один крайний случай, когда static имеет удивительный эффект (по крайней мере, для меня). Стандарт C ++ 03 в 14.6.4.2/1 гласит:

Для вызова функции, который зависит от параметра шаблона, если имя функции является неквалифицированным идентификатором, но не идентификатором шаблона , функции-кандидаты находятся с использованием обычных правил поиска (3.4.1, 3.4.2), за исключением того, что:

• Для части поиска с использованием поиска без определения имени (3.4.1) найдены только объявления функций с внешней связью из контекста определения шаблона.
• Для части поиска, использующей связанные пространства имен (3.4.2), обнаруживаются только объявления функций с внешней связью, найденные либо в контексте определения шаблона, либо в контексте создания шаблона.

...

Код ниже будет звонить, foo(void*)а не так, foo(S const &)как вы могли ожидать.

template <typename T>
int b1 (T const & t)
{
  foo(t);
}

namespace NS
{
  namespace
  {
    struct S
    {
    public:
      operator void * () const;
    };

    void foo (void*);
    static void foo (S const &);   // Not considered 14.6.4.2(b1)
  }

}

void b2()
{
  NS::S s;
  b1 (s);
}

Само по себе это, вероятно, не так уж и сложно, но подчеркивает, что для полностью совместимого компилятора C ++ (то есть с поддержкой export) staticключевое слово по-прежнему будет иметь функциональность, недоступную другим способом.

// bar.h
export template <typename T>
int b1 (T const & t);

// bar.cc
#include "bar.h"
template <typename T>
int b1 (T const & t)
{
  foo(t);
}

// foo.cc
#include "bar.h"
namespace NS
{
  namespace
  {
    struct S
    {
    };

    void foo (S const & s);  // Will be found by different TU 'bar.cc'
  }
}

void b2()
{
  NS::S s;
  b1 (s);
}

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

Обновление для Modern C ++

Начиная с C ++ '11, члены безымянного пространства имен неявно имеют внутреннюю связь (3.5 / 4):

Неназванное пространство имен или пространство имен, объявленное прямо или косвенно в безымянном пространстве имен, имеет внутреннюю связь.

Но в то же время 14.6.4.2/1 был обновлен, чтобы убрать упоминание о связи (это взято из C ++ '14):

Для вызова функции, где postfix-выражение является зависимым именем, функции-кандидаты находятся с использованием обычных правил поиска (3.4.1, 3.4.2), за исключением того, что:

• Для части поиска с использованием поиска без определения имени (3.4.1) найдены только объявления функций из контекста определения шаблона.

• Для части поиска, использующей связанные пространства имен (3.4.2), найдены только объявления функций, найденные либо в контексте определения шаблона, либо в контексте создания экземпляра шаблона.

В результате этого конкретного различия между статическими и неназванными членами пространства имен больше не существует.

Недавно я начал заменять статические ключевые слова анонимными пространствами имен в моем коде, но сразу столкнулся с проблемой, когда переменные в пространстве имен больше не были доступны для проверки в моем отладчике. Я использовал VC60, поэтому я не знаю, не является ли это проблемой с другими отладчиками. Мой обходной путь состоял в том, чтобы определить пространство имен 'module', где я дал ему имя моего файла cpp.

Например, в моем файле XmlUtil.cpp я определяю пространство имен XmlUtil_I { ... }для всех переменных и функций моего модуля. Таким образом, я могу применить XmlUtil_I::квалификацию в отладчике для доступа к переменным. В этом случае _Iон отличается от публичного пространства имен, такого, XmlUtilкоторое я, возможно, захочу использовать в другом месте.

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

Использование статического ключевого слова для этой цели не рекомендуется стандартом C ++ 98. Проблема со статическим в том, что он не относится к определению типа. Это также перегруженное ключевое слово, используемое по-разному в разных контекстах, поэтому безымянные пространства имен немного упрощают вещи.

Из опыта я просто отмечу, что, хотя это способ C ++ поместить ранее статические функции в анонимное пространство имен, старые компиляторы могут иногда иметь проблемы с этим. В настоящее время я работаю с несколькими компиляторами для наших целевых платформ, и более современный компилятор Linux хорошо размещает функции в анонимном пространстве имен.

Но более старый компилятор, работающий на Solaris, который мы используем до неуказанного будущего выпуска, иногда принимает его, а иногда отмечает его как ошибку. Ошибка не в том, что меня беспокоит, а в том, что он может делать, когда принимает это. Поэтому, пока мы не станем современными по всем направлениям, мы все еще будем использовать статические (обычно классовые) функции, где мы предпочитаем анонимное пространство имен.

Кроме того, если кто-то использует статическое ключевое слово для переменной, как в этом примере:

namespace {
   static int flag;
}

Это не будет видно в файле сопоставления

Отличие компилятора между анонимными пространствами имен и статическими функциями можно увидеть при компиляции следующего кода.

#include <iostream>

namespace
{
    void unreferenced()
    {
        std::cout << "Unreferenced";
    }

    void referenced()
    {
        std::cout << "Referenced";
    }
}

static void static_unreferenced()
{
    std::cout << "Unreferenced";
}

static void static_referenced()
{
    std::cout << "Referenced";
}

int main()
{
    referenced();
    static_referenced();
    return 0;
}

Компиляция этого кода с VS 2017 (указание флага предупреждения уровня 4 / W4 для включения предупреждения C4505: удаленная локальная функция была удалена ) и gcc 4.9 с флагом -Wunused-function или -Wall показывает, что VS 2017 будет выдавать предупреждение только для неиспользуемая статическая функция. gcc 4.9 и выше, а также clang 3.3 и выше, будут выдавать предупреждения для функции без ссылок в пространстве имен, а также предупреждение о неиспользуемой статической функции.

Живая демоверсия gcc 4.9 и MSVC 2017

Лично я предпочитаю статические функции над безымянными пространствами имен по следующим причинам:

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

• Некоторые (более старые) компиляторы могут рассматривать функции в пространствах имен как внешние. В VS2017 они все еще внешние. По этой причине, даже если функция находится в безымянном пространстве имен, вы все равно можете пометить их как статические.

• Статические функции ведут себя очень похоже в C или C ++, тогда как безымянные пространства имен, очевидно, являются только C ++. безымянные пространства имен также добавляют дополнительный уровень отступа, и мне это не нравится :)

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

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

• Анонимные пространства имен могут быть вложены друг в друга, обеспечивая несколько уровней защиты, из которых символы не могут выйти.
• Несколько анонимных пространств имен могут быть помещены в один и тот же исходный файл, создавая фактически разные области статического уровня в одном и том же файле.

Мне было бы интересно узнать, использовал ли кто-нибудь анонимные пространства имен в реальном коде.

Разница заключается в названии искаженного идентификатора ( _ZN12_GLOBAL__N_11bEvs _ZL1b, что на самом деле не имеет значения, но оба они собраны в локальные символы в таблице символов (отсутствие .globalдирективы asm).

#include<iostream>
namespace {
   int a = 3;
}

static int b = 4;
int c = 5;

int main (){
    std::cout << a << b << c;
}

        .data
        .align 4
        .type   _ZN12_GLOBAL__N_11aE, @object
        .size   _ZN12_GLOBAL__N_11aE, 4
_ZN12_GLOBAL__N_11aE:
        .long   3
        .align 4
        .type   _ZL1b, @object
        .size   _ZL1b, 4
_ZL1b:
        .long   4
        .globl  c
        .align 4
        .type   c, @object
        .size   c, 4
c:
        .long   5
        .text

Что касается вложенного анонимного пространства имен:

namespace {
   namespace {
       int a = 3;
    }
}

        .data
        .align 4
        .type   _ZN12_GLOBAL__N_112_GLOBAL__N_11aE, @object
        .size   _ZN12_GLOBAL__N_112_GLOBAL__N_11aE, 4
_ZN12_GLOBAL__N_112_GLOBAL__N_11aE:
        .long   3
        .align 4
        .type   _ZL1b, @object
        .size   _ZL1b, 4

Все анонимные пространства имен 1-го уровня в модуле перевода объединены друг с другом, все вложенные анонимные пространства имен 2-го уровня в модуле перевода объединены друг с другом

Вы также можете иметь вложенное (встроенное) пространство имен в анонимном пространстве имен

namespace {
   namespace A {
       int a = 3;
    }
}

        .data
        .align 4
        .type   _ZN12_GLOBAL__N_11A1aE, @object
        .size   _ZN12_GLOBAL__N_11A1aE, 4
_ZN12_GLOBAL__N_11A1aE:
        .long   3
        .align 4
        .type   _ZL1b, @object
        .size   _ZL1b, 4

which for the record demangles as:
        .data
        .align 4
        .type   (anonymous namespace)::A::a, @object
        .size   (anonymous namespace)::A::a, 4
(anonymous namespace)::A::a:
        .long   3
        .align 4
        .type   b, @object
        .size   b, 4

Вы также можете иметь анонимные встроенные пространства имен, но, насколько я могу судить, inlineна анонимное пространство имен влияет 0

inline namespace {
   inline namespace {
       int a = 3;
    }
}

_ZL1b: _Zозначает, что это искаженный идентификатор. Lозначает, что это локальный символ static. 1длина идентификатора, bа затем идентификаторb

_ZN12_GLOBAL__N_11aE _Zозначает, что это искаженный идентификатор. Nозначает, что это пространство имен 12- это длина имени анонимного пространства имен _GLOBAL__N_1, затем имя анонимного пространства имен _GLOBAL__N_1, затем 1длина идентификатора a, aэто идентификаторa и Eзакрытие идентификатора, который находится в пространстве имен.

_ZN12_GLOBAL__N_11A1aE такой же, как указано выше, за исключением того, что есть еще один уровень пространства имен в нем 1A