Безіменні / анонімні простори імен та статичні функції

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

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

Ви можете подумати, що така функція буде марною - оскільки ви не можете вказати назву простору імен, неможливо отримати доступ до чого-небудь всередині неї ззовні. Але ці безіменні простору імен є доступними в файлі вони створили в, як якщо б ви мали неявне з допомогою придаткового до них.

Моє запитання: чому або коли це було б кращим, ніж використання статичних функцій? Або вони по суті є двома способами зробити саме те саме?

Стандарт C ++ читається в розділі 7.3.1.1, безіменні простори імен, параграф 2:

Використання статичного ключового слова припинено при оголошенні об'єктів в області простору імен, простір безіменних імен надає чудову альтернативу.

Статичний характер стосується лише імен об'єктів, функцій та анонімних об'єднань, а не для введення декларацій.

Редагувати:

Рішення про відмову від використання статичного ключового слова (впливати на видимість змінної декларації в блоці перекладу) було скасовано ( посилання ). У цьому випадку використання статичного чи безіменного простору імен повертаються до принципово двох способів зробити точну саму річ. Для більш детальної дискусії дивіться це питання ТАК.

Переважно неіменовані простори імен дозволяють визначати локальні типи перекладу-одиниці. Будь ласка, дивіться це питання ТА для отримання більш детальної інформації.

Кредит приділяється Майку Персі за те, що він довів це до моєї уваги.

Якщо розмістити методи в анонімному просторі імен, ви запобігаєте випадковому порушенню Правила однієї дефініції , що дозволяє вам ніколи не хвилюватися щодо того, щоб називати свої допоміжні методи так само, як і інші способи, з якими ви можете зв’язатись.

І, як вказує luke, анонімні простори імен надаються перевагою стандарту над статичними елементами.

Є один крайній випадок, коли статика має дивовижний ефект (принаймні, це було для мене). Стандарт 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.

Оновлення для сучасного C ++

Станом на C ++ '11, члени простої імені безіменного мають внутрішній зв'язок неявно (3.5 / 4):

Неназваний простір імен або простір імен, оголошений прямо або опосередковано в просторі імен без імені, має внутрішні зв'язки.

Але в той же час 14.6.4.2/1 було оновлено, щоб видалити згадування про зв'язок (це взято з C ++ '14):

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

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

• Для частини пошуку з використанням пов'язаних просторів імен (3.4.2) знаходять лише декларації функцій, які знаходяться або в контексті визначення шаблону, або в контексті інстанції шаблону.

В результаті цього особливої ​​різниці між статичними та безіменними членами простору імен вже не існує.

Нещодавно я почав замінювати статичні ключові слова анонімними просторами імен у своєму коді, але негайно зіткнувся з проблемою, коли змінні в просторі імен більше не були доступні для перевірки в моєму налагоджувачі. Я використовував VC60, тому не знаю, чи це проблема не з іншими налагоджувачами. Моє вирішення полягало у визначенні простору імен 'модуль', де я назвав його моєму файлу 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-функцією або -Wall показує, що VS 2017 видасть лише попередження для невикористану статичну функцію. gcc 4.9 і новіші, а також кланг 3.3 і новіші, створюватиме попередження про невиділену функцію в просторі імен, а також попередження про невикористану статичну функцію.

Демонстраційна демонстрація gcc 4.9 та MSVC 2017

Особисто я віддаю перевагу статичним функціям над безіменними просторами імен з наступних причин:

• З самого визначення функції очевидно і зрозуміло, що це приватне підрозділ перекладу, де він складений. З безіменним простором імен вам може знадобитися прокрутка та пошук, щоб побачити, чи є функція в просторі імен.

• Деякі (старіші) компілятори функції в просторах імен можуть розглядатися як зовнішні. У VS2017 вони все ще зовнішні. З цієї причини, навіть якщо функція знаходиться в безіменному просторі імен, ви все одно можете позначати їх статичними.

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

Тож я радий бачити, що використання статики для функцій вже не застаріло .

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

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

Мені було б цікаво дізнатися, чи хтось використовував анонімні простори імен у реальному коді.

Різниця полягає у назві розробленого ідентифікатора ( _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