Adsız / anonim ad alanları ve statik işlevler

C ++ 'ın bir özelliği, şöyle adlandırılmamış (anonim) ad alanları oluşturma yeteneğidir:

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

Böyle bir özelliğin işe yaramayacağını düşünürsünüz - ad alanının adını belirleyemediğiniz için, içerideki herhangi bir şeye dışarıdan erişmek imkansızdır. Fakat bu isimsiz ad alanları vardır onlara örtük kullanılarak-maddesini varmış gibi, onlar oluşturulan dosyanın içinde erişilebilir.

Benim sorum şu, neden veya ne zaman bu statik işlevleri kullanmak için tercih edilir? Yoksa tam olarak aynı şeyi yapmanın iki yolu mu?

C ++ Standardı, bölüm 7.3.1.1 Adsız ad alanları, paragraf 2'de okur:

Bir ad alanı kapsamındaki nesneler bildirilirken, statik anahtar kelimenin kullanımı kullanımdan kaldırılır, adsız ad alanı üstün bir alternatif sağlar.

Statik, bildirimlerin yazılması için değil, yalnızca nesnelerin, işlevlerin ve anonim birliklerin adları için geçerlidir.

Düzenle:

Statik anahtar kelimenin bu kullanımından kaldırılma kararı (bir çeviri birimindeki değişken bildirimin görünürlüğünü etkileme) tersine çevrildi ( ref ). Bu durumda, statik veya adsız bir ad alanı kullanmak, aslında aynı şeyi yapmanın iki yolu haline gelmiştir. Daha fazla tartışma için lütfen bu SO sorusuna bakın.

Adsız ad alanları, çeviri birimi yerel türlerini tanımlamanıza izin verme avantajına sahiptir. Daha fazla ayrıntı için lütfen bu SO sorusuna bakın.

Kredi dikkatimi çektiği için Mike Percy'ye gidiyor .

Yöntemleri anonim bir ad alanına koymak, Tek Tanımlama Kuralını yanlışlıkla ihlal etmenizi önleyerek yardımcı yöntemlerinizi bağlayabileceğiniz diğer yöntemlerle aynı şekilde adlandırmanız konusunda asla endişelenmenize izin vermez.

Ve luke tarafından işaret edildiği gibi, standart tarafından statik üyelere göre anonim ad alanları tercih edilir.

Statikin şaşırtıcı bir etkiye sahip olduğu bir kenar durumu vardır (en azından benim içindi). 14.6.4.2/1'deki C ++ 03 Standardı:

Şablon parametresine bağlı bir işlev çağrısı için, işlev adı nitelenmemiş bir kimlikse ancak bir şablon kimliği değilse , aday işlevler, olağan arama kuralları (3.4.1, 3.4.2) kullanılarak bulunur:

• Aramanın nitelenmemiş ad araması (3.4.1) kullanan kısmı için, yalnızca şablon tanımı bağlamından dış bağlantısı olan işlev bildirimleri bulunur.
• Aramanın ilişkili ad alanlarını (3.4.2) kullanan kısmı için, yalnızca şablon tanımı bağlamında veya şablon örnekleme bağlamında bulunan harici bağlantıya sahip işlev bildirimleri bulunur.

...

Aşağıdaki kod arayabilir foo(void*)ve foo(S const &)beklediğiniz gibi değil .

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);
}

Kendi içinde bu muhtemelen büyük bir anlaşma değil, ama tam uyumlu bir C ++ derleyicisi (yani destekli bir export) için staticanahtar kelimenin hala başka hiçbir şekilde mevcut olmayan işlevselliğe sahip olacağını vurgulamaktadır.

// 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);
}

Adsız ad alanımızdaki işlevin ADL kullanan şablonlarda bulunmamasını sağlamanın tek yolu, bunu yapmaktır static.

Modern C ++ Güncelleştirmesi

C ++ '11 itibariyle, adsız bir ad alanının üyeleri dolaylı olarak iç bağlantıya sahiptir (3.5 / 4):

Adsız bir ad alanı veya adsız bir ad alanı içinde doğrudan veya dolaylı olarak bildirilen bir ad alanı dahili bağlantıya sahiptir.

Ancak aynı zamanda, bağlantıdan bahsetmek için 14.6.4.2/1 güncellendi (bu C ++ '14'ten alınmıştır):

Postfix-ifadesinin bağımlı bir isim olduğu bir işlev çağrısı için, aday işlevler, aşağıdakiler dışında olağan arama kuralları (3.4.1, 3.4.2) kullanılarak bulunur:

• Aramanın nitelenmemiş ad araması (3.4.1) kullanan kısmı için, yalnızca şablon tanımı bağlamından işlev bildirimleri bulunur.

• Aramanın ilişkili ad alanlarını (3.4.2) kullanan kısmı için, yalnızca şablon tanımı bağlamında veya şablon örnekleme bağlamında bulunan işlev bildirimleri bulunur.

Sonuç, statik ve adsız ad alanı üyeleri arasındaki bu farkın artık mevcut olmamasıdır.

Son zamanlarda kodumda anonim ad alanlarıyla statik anahtar sözcükleri değiştirmeye başladım, ancak hemen ad alanındaki değişkenlerin artık hata ayıklayıcımda inceleme için mevcut olmadığı bir soruna rastladım. VC60 kullanıyordum, bu yüzden diğer hata ayıklayıcılarla ilgili bir sorun olup olmadığını bilmiyorum. Benim geçici çözüm bir 'modül' ad alanı tanımlamak oldu, burada cpp dosyama adını verdi.

Örneğin, XmlUtil.cpp dosyamda, XmlUtil_I { ... }tüm modül değişkenlerim ve işlevlerim için bir ad alanı tanımladım . Bu şekilde XmlUtil_I::değişkenlere erişmek için hata ayıklayıcıdaki kalifikasyonu uygulayabilirim . Bu durumda, başka bir yerde kullanmak isteyebileceğim _Igibi genel bir ad alanından ayırır XmlUtil.

Bu yaklaşımın gerçekten anonim olana kıyasla potansiyel bir dezavantajı, birisinin diğer modüllerde ad alanı niteleyicisini kullanarak istenen statik kapsamı ihlal edebileceğidir. Bunun büyük bir endişe olup olmadığını bilmiyorum.

Bu amaçla statik anahtar kelime kullanımı C ++ 98 standardı tarafından kullanımdan kaldırılmıştır. Statik problem, tip tanımına uygulanmamasıdır. Ayrıca, farklı bağlamlarda farklı şekillerde kullanılan aşırı yüklenmiş bir anahtar kelime olduğundan, adsız ad alanları işleri biraz basitleştirir.

Deneyimden, anonim ad alanına eski statik işlevleri koymak için C ++ yolu olsa da, eski derleyicilerin bazen bu konuda sorun yaşayabileceğini unutmayın. Şu anda hedef platformlarımız için birkaç derleyici ile çalışıyorum ve daha modern Linux derleyicisi, işlevleri anonim ad alanına yerleştirmekle sorun değil.

Ancak, gelecekte belirtilmeyen bir sürüm yayınlanıncaya kadar beklediğimiz Solaris üzerinde çalışan eski bir derleyici bazen kabul edecek ve bazen de hata olarak işaretleyecektir. Hata beni endişelendiren şey değil, kabul ettiğinde ne yapıyor olabilir . Bu yüzden tahtada modern olana kadar, anonim ad alanını tercih ettiğimiz statik (genellikle sınıf kapsamındaki) işlevleri kullanıyoruz.

Ayrıca, bu örnek gibi bir değişkende statik anahtar kelime kullanılıyorsa:

namespace {
   static int flag;
}

Eşleme dosyasında görülmez

Anonim ad alanları ve statik işlevler arasında derleyiciye özgü bir fark, aşağıdaki kodu derlerken görülebilir.

#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;
}

Bu kodu VS 2017 ile derlemek (C4505 uyarısını etkinleştirmek için seviye 4 uyarı bayrağını / W4'ü belirtmek: referanslandırılmamış yerel işlev kaldırıldı ) ve -Wunused işlevi veya -Wall bayrağıyla gcc 4.9, VS 2017'nin yalnızca kullanılmayan statik fonksiyon. gcc 4.9 ve üstü, clang 3.3 ve üstü, isim alanındaki referanssız fonksiyon için uyarılar ve kullanılmayan statik fonksiyon için bir uyarı verecektir.

Gcc 4.9 ve MSVC 2017 canlı demosu

Şahsen ben aşağıdaki nedenlerden dolayı isimsiz isim alanlarına göre statik fonksiyonları tercih ediyorum:

• Yalnızca işlev tanımından derlendiği çeviri birimine özel olduğu açık ve nettir. Adsız ad alanı ile, bir işlevin ad alanında olup olmadığını görmek için ekranı kaydırıp aramanız gerekebilir.

• Ad alanlarındaki işlevler, bazı (eski) derleyiciler tarafından extern olarak değerlendirilebilir. VS2017'de hala extern. Bu nedenle, bir işlev adsız ad alanında olsa bile, bunları statik olarak işaretlemek isteyebilirsiniz.

• Statik işlevler C veya C ++ 'da çok benzer davranırken, isimsiz ad alanları sadece C ++' dır. isimsiz ad alanları da girinti ekstra seviye eklemek ve ben bunu sevmiyorum :)

Bu nedenle, işlevler için statik kullanımının artık kullanılmadığını görmekten mutluluk duyuyorum .

Bu özelliği yalnızca şimdi sorunuzu okurken öğrendikten sonra sadece spekülasyon yapabilirim. Bu, dosya düzeyinde bir statik değişkene göre çeşitli avantajlar sağlıyor gibi görünüyor:

• Anonim ad alanları, sembollerin kaçamayacağı birden fazla koruma düzeyi sağlayarak iç içe yerleştirilebilir.
• Aynı kaynak dosyaya birkaç anonim ad alanı yerleştirilebilir ve böylece aynı dosya içinde farklı statik düzey kapsamları oluşturulabilir.

Herkes gerçek kodda anonim ad alanları kullandıysanız öğrenmek istiyorum.

Fark, karıştırılmış tanımlayıcının adıdır ( _ZN12_GLOBAL__N_11bEvs _ZL1b, gerçekten önemli değildir, ancak her ikisi de sembol tablosundaki yerel sembollere birleştirilir ( .globalasm yönergesinin yokluğu ).

#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

Yuvalanmış anonim bir ad alanına gelince:

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

Çeviri birimindeki tüm 1. düzey anonim ad alanları birbirleriyle birleştirilir, Çeviri birimindeki tüm 2. düzey iç içe anonim ad alanları birbirleriyle birleştirilir

Anonim bir ad alanında iç içe (satır içi) ad alanınız da olabilir

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

Ayrıca anonim satır içi ad alanlarına sahip olabilirsiniz, ancak anlayabildiğim kadarıyla inlineanonim bir ad alanında 0 etkisi vardır

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

_ZL1b: _Zbunun karışık bir tanımlayıcı olduğu anlamına gelir. Lanlamına gelen yerel bir semboldür static. 1tanımlayıcının bve ardından tanımlayıcının uzunluğudurb

_ZN12_GLOBAL__N_11aE _Zbunun karıştırılmış bir tanımlayıcı olduğu anlamına gelir. NBu ad olduğu anlamına gelir 12anonim ad adı uzunluğu _GLOBAL__N_1, daha sonra anonim isim alanı _GLOBAL__N_1, daha sonra 1tanımlayıcının uzunluğu a, atanımlayıcıdır ave Etanımlayıcı kapanır bir isim alanı bulunur.

_ZN12_GLOBAL__N_11A1aE içinde başka bir ad alanı düzeyi olması dışında yukarıdakiyle aynıdır 1A