Konsequenter Ansatz zum Umbenennen von Namespaces in C++

Question

Bei der Verwendung verschachtelter Namespaces sind manchmal vollständig qualifizierte Namen ziemlich lang. Ich weiß, dass ich namespace abc = aaa::bbb::ccc verwenden kann, um die Menge des Tippens zu reduzieren (es kann in einigen Fällen auch die Lesbarkeit verbessern).

Ich bin mir nicht sicher, was jedoch der beste Weg ist, um diese Umbenennung über alle Dateien in einem Projekt zu erreichen. Der direkte Ansatz (d. H. Das Umbenennen langer Namespaces auf Benutzerebene) kann dazu führen, dass verschiedene Kurznamen für den gleichen vollständig qualifizierten Namen in verschiedenen Dateien verwendet werden. Also habe ich mir überlegt, einen konsistenteren Weg zu finden.

Zum Beispiel nehmen wir an, so etwas wie:

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

Ich dachte, ein Kopf pro Verzeichnis einschließlich der reduzierten Namen zu erstellen. Zum Beispiel würde project/client/core/core.hnamespace pr_cl_core = project::client::core enthalten (ich weiß, dass das Beispiel für diesen kurzen Namen eher schlecht ist, aber in realen Projekten machen sie mehr Sinn). Dann würde ich core.h in alle Header-Dateien in project/client/core einfügen, so dass, wenn ein Header aus diesem Verzeichnis enthalten ist, sagen wir project/client/plugin/plugin_foo.h, die kurzen Namespace-Versionen sind leicht verfügbar.

Ist das ein guter Ansatz, dies zu tun? Gibt es einen anderen besseren Weg?

Ich habe mehrere Fragen zu C++ - Namespaces auf SO (zum Beispiel 1 und 2) gefunden, aber keiner von ihnen bezieht sich auf wie Projekt Namensumbenennung projektweit zu lösen.

EDIT: Darüber hinaus könnte ein solcher Mechanismus verwendet werden, um lange Namensräume (wie Boosts) für ein ganzes Projekt systematisch umzubenennen. Zum Beispiel umbenennen ich in der Regel einige Namensräume wie:

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

Zur Zeit mache ich das auf einer pro-Übersetzung Einheitsbasis, aber ich würde es tun einen globalen Ansatz für das gesamte Projekt mit.

Answer 1

Ich würde argumentieren, wenn Sie wiederholt lange Namespace-Namen eingeben müssen, dann ist etwas in Ihrer Namespace-Hierarchie falsch.

Angenommen, Sie hätten das gleiche mit Klassen, immer wieder selbst tippen obj->sub()->subsub()->some_method() eingeben. Dies wäre eine Verletzung der Law of Demeter. Im Fall von Klassen würden Sie Ihren Code (durch das Schreiben von Wrapper-Funktionen) umgestalten, so dass Klassen in der Hierarchie nur auf eine Ebene mehr auf Methoden zugreifen müssen.

Das gleiche sollte mit Namensräumen durchgeführt werden: Wenn Sie project::client::core anrufen, dann sollten Sie Wrapper-Funktionen/Klassen in client schreiben die notwendigen Schnittstellen zu project belichten. Wenn Sie dies überall tun müssen, warum sollten Sie Ihre Namensraumstruktur nicht so abflachen, dass client und core auf demselben Niveau liegen?

Die Tatsache, dass Boost verschachtelten Namespace verwendet, ist nur teilweise wahr, weil die meisten verschachtelten Namespaces wie aux und detail nicht von Clients aufgerufen werden sollen. Z.B. Boost.MPL ist ein wirklich gutes Beispiel für eine Bibliothek, die sorgfältig darauf achtet, verschachtelte Namespaces nicht freizugeben.