¿Por qué se utilizan espacios de nombres sin nombre y cuáles son sus beneficios?

Me acabo de unir a un nuevo proyecto de software C ++ y estoy tratando de entender el diseño. El proyecto hace un uso frecuente de espacios de nombres sin nombre. Por ejemplo, algo como esto puede ocurrir en un archivo de definición de clase:

// newusertype.cc
namespace {
  const int SIZE_OF_ARRAY_X;
  const int SIZE_OF_ARRAY_Y;
  bool getState(userType*,otherUserType*);
}

newusertype::newusertype(...) {...

¿Cuáles son las consideraciones de diseño que pueden hacer que uno use un espacio de nombres sin nombre? ¿Cuáles son las ventajas y desventajas?

Los espacios de nombres sin nombre son una utilidad para hacer que una unidad de traducción de identificadores sea local. Se comportan como si eligiera un nombre único por unidad de traducción para un espacio de nombres:

namespace unique { /* empty */ }
using namespace unique;
namespace unique { /* namespace body. stuff in here */ }

El paso adicional de usar el cuerpo vacío es importante, por lo que ya puede hacer referencia dentro del cuerpo del espacio de nombres a identificadores como los ::nameque están definidos en ese espacio de nombres, ya que la directiva using ya se llevó a cabo.

Esto significa que puede tener funciones gratuitas llamadas (por ejemplo) helpque pueden existir en varias unidades de traducción y no entrarán en conflicto en el momento del enlace. El efecto es casi idéntico al uso de la staticpalabra clave utilizada en C, que puede incluir en la declaración de identificadores. Los espacios de nombres sin nombre son una alternativa superior, pudiendo incluso hacer que una unidad de traducción de tipos sea local.

namespace { int a1; }
static int a2;

Ambos ason unidades de traducción locales y no entrarán en conflicto en el momento del enlace. Pero la diferencia es que a1en el espacio de nombres anónimo obtiene un nombre único.

Lea el excelente artículo en comeau-computing ¿Por qué se usa un espacio de nombres sin nombre en lugar de estático? ( Espejo de Archive.org ).

Tener algo en un espacio de nombres anónimo significa que es local para esta unidad de traducción (archivo .cpp y todas sus inclusiones), esto significa que si otro símbolo con el mismo nombre se define en otro lugar, no habrá una violación de la regla de una definición (ODR).

Esto es lo mismo que la forma en C de tener una variable global estática o una función estática, pero también se puede usar para definiciones de clases (y se debe usar en lugar de staticen C ++).

Todos los espacios de nombres anónimos en el mismo archivo se tratan como el mismo espacio de nombres y todos los espacios de nombres anónimos en archivos diferentes son distintos. Un espacio de nombres anónimo es el equivalente a:

namespace __unique_compiler_generated_identifer0x42 {
    ...
}
using namespace __unique_compiler_generated_identifer0x42;

El espacio de nombres sin nombre limita el acceso de clase, variable, función y objetos al archivo en el que está definido. La funcionalidad del espacio de nombres sin nombre es similar a la staticpalabra clave en C / C ++.
staticLa palabra clave limita el acceso de la variable global y la función al archivo en el que están definidas.
Existe una diferencia entre el espacio de nombres sin nombre y la staticpalabra clave debido a que el espacio de nombres sin nombre tiene ventaja sobre el estático. staticLa palabra clave se puede utilizar con variable, función y objetos, pero no con la clase definida por el usuario.
Por ejemplo:

static int x;  // Correct 

Pero,

static class xyz {/*Body of class*/} //Wrong
static structure {/*Body of structure*/} //Wrong

Pero lo mismo puede ser posible con un espacio de nombres sin nombre. Por ejemplo,

 namespace {
           class xyz {/*Body of class*/}
           static structure {/*Body of structure*/}
  } //Correct

Además de las otras respuestas a esta pregunta, el uso de un espacio de nombres anónimo también puede mejorar el rendimiento. Como los símbolos dentro del espacio de nombres no necesitan ningún vínculo externo, el compilador tiene más libertad para realizar una optimización agresiva del código dentro del espacio de nombres. Por ejemplo, una función que se llama varias veces una vez en un bucle se puede insertar sin ningún impacto en el tamaño del código.

Por ejemplo, en mi sistema, el siguiente código toma alrededor del 70% del tiempo de ejecución si se usa el espacio de nombres anónimo (x86-64 gcc-4.6.3 y -O2; tenga en cuenta que el código adicional en add_val hace que el compilador no quiera incluir dos veces).

#include <iostream>

namespace {
  double a;
  void b(double x)
  {
    a -= x;
  }
  void add_val(double x)
  {
    a += x;
    if(x==0.01) b(0);
    if(x==0.02) b(0.6);
    if(x==0.03) b(-0.1);
    if(x==0.04) b(0.4);
  }
}

int main()
{
  a = 0;
  for(int i=0; i<1000000000; ++i)
    {
      add_val(i*1e-10);
    }
  std::cout << a << '\n';
  return 0;
}

Un espacio de nombres anónimo hace que las variables, funciones, clases, etc. adjuntas estén disponibles solo dentro de ese archivo. En su ejemplo, es una forma de evitar las variables globales. No hay diferencia de rendimiento en tiempo de ejecución o tiempo de compilación.

No hay tanta ventaja o desventaja aparte de "¿Quiero que esta variable, función, clase, etc. sea pública o privada?"

El ejemplo muestra que las personas del proyecto al que se unió no comprenden los espacios de nombres anónimos :)

namespace {
    const int SIZE_OF_ARRAY_X;
    const int SIZE_OF_ARRAY_Y;

No es necesario que estén en un espacio de nombres anónimo, ya que el constobjeto ya tiene un enlace estático y, por lo tanto, no puede entrar en conflicto con los identificadores del mismo nombre en otra unidad de traducción.

    bool getState(userType*,otherUserType*);
}

Y esto es en realidad una pesimismo: getState()tiene vinculación externa. Por lo general, es mejor preferir el enlace estático, ya que eso no contamina la tabla de símbolos. Es mejor escribir

static bool getState(/*...*/);

aquí. Caí en la misma trampa (hay una redacción en el estándar que sugiere que las estadísticas de archivos de alguna manera están en desuso a favor de los espacios de nombres anónimos), pero al trabajar en un gran proyecto de C ++ como KDE, hay muchas personas que vuelven la cabeza de la manera correcta alrededor de nuevo :)