Enfoque coherente para cambiar el nombre de espacios de nombres en C++

Question

Cuando se utilizan espacios de nombres anidados, a veces los nombres totalmente calificados terminan siendo bastante largos. Sé que puedo usar namespace abc = aaa::bbb::ccc para reducir la cantidad de tipeo (también puede mejorar la legibilidad en algunos casos).

No estoy seguro, sin embargo, cuál es la mejor manera de lograr este cambio de nombre en todos los archivos de un proyecto. El enfoque directo (es decir, para cambiar el nombre de los espacios de nombres largos por usuario) podría llevar a utilizar diferentes nombres cortos para el mismo nombre completo en archivos diferentes. Entonces, estaba pensando en encontrar una forma más consistente de hacer esto.

Por ejemplo, vamos a suponer algo como:

project 
    |- client 
    | |- core 
    | |- plugin 
    | |- util 
    |- server 
     ... 

estaba pensando para crear un encabezado por directorio que incluye los nombres reducidos. Por ejemplo, project/client/core/core.h contendría namespace pr_cl_core = project::client::core (sé que el ejemplo para este nombre corto es bastante pobre, pero en proyectos reales tienen más sentido). Luego, incluiría core.h en todos los archivos de encabezado en project/client/core, de modo que cuando se incluye un encabezado de ese directorio en, digamos, project/client/plugin/plugin_foo.h, las versiones cortas del espacio de nombres estén disponibles.

¿Es este un buen enfoque para hacerlo? ¿Hay alguna otra forma mejor?

He encontrado varias preguntas sobre espacios de nombres C++ en SO (por ejemplo, 1 y 2), pero ninguna de ellas se relaciona con la forma de resolver el cambio de nombre del espacio de nombre en todo el proyecto.

EDIT: Además, un mecanismo de este tipo se podría utilizar para cambiar el nombre sistemáticamente de espacios de nombres largos (como los de Boost) para un proyecto completo. Por ejemplo, normalmente cambiar el nombre de algunos espacios de nombres como:

namespace ip = boost::asio::ip; 
namespace ptime = boost::posix_time; 

Actualmente hago esto sobre una base per-traducción unidad, pero me gustaría hacerlo mediante una estrategia global para todo el proyecto.

Answer 1

Me atrevería a decir que si repetidamente tiene que escribir nombres largos de espacio de nombres, entonces algo está mal en su jerarquía de espacio de nombres.

Supongamos que tiene lo mismo con las clases, y se encuentra repetidamente escribiendo obj->sub()->subsub()->some_method(). Esto sería una violación del Law of Demeter. En el caso de las clases, debe refactorizar su código (escribiendo funciones de contenedor) para que las clases de la jerarquía solo tengan que acceder a los métodos un nivel arriba.

El mismo se debe hacer con los espacios de nombres: si tiene que llamar project::client::core entonces usted debe escribir funciones de contenedor/clases en client para exponer las interfaces necesarias para project. Si necesita hacer esto por todos lados, ¿por qué no aplanar su estructura de espacio de nombres para que client y core estén en el mismo nivel?

El hecho de que Boost usa el espacio de nombres anidado es parcialmente cierto, porque los clientes no deben llamar a la mayoría de los espacios de nombres anidados como aux y detail. P.ej. Boost.MPL es un muy buen ejemplo de una biblioteca que tiene cuidado de no exponer innecesariamente espacios de nombres anidados.