Softwareentwicklung in C++ - ASC

460 14. Namespaces
zu vermeiden. Durch solche Bezeichner besteht die große Gefahr, dass man
irrtümlich Namespaces, die miteinander nichts zu tun haben, zu einem gemeinsamen
größeren Namespace vereint, bloß weil die Namen zufällig dieselben
sind. Das ist sicher nicht im Sinne des Erfinders und vor allem sind
dadurch Name-Clashes praktisch vorprogrammiert. Nun gibt es aber Fälle,
in denen man kein explizites using für viele verschiedene Elemente aus einem
Namespace schreiben will, weil man jedes einzelne für sich eigentlich nicht
oft genug braucht, um das zu rechtfertigen. Andererseits aber braucht man
trotzdem den Scope auf diesen Namespace ziemlich oft, weil man es eben
mit vielen verschiedenen Namespaces zu tun hat. Für solche Fälle gibt es
die Möglichkeit, einem Namespace ein Alias zu geben. Wollte man z.B. das
Alias DS für Datastructures_ im Code verwenden, so kann man folgendes
Statement schreiben:
namespace DS = Datastructures_;
Ich würde jedoch wirklich zur Vorsicht mahnen, denn man kann Code dadurch
ziemlich verwirrend und damit unlesbar machen.
Zu guter Letzt möchte ich noch auf eine Möglichkeit hinweisen, die man
mit Namespaces hat und die eigentlich wie ein Paradoxon klingt: Es gibt
auch sogenannte unnamed Namespaces. Man kann z.B. die folgenden Zeilen
schreiben:
1 namespace
2 {
3 void f ( )
4 {
5 // whatever code
6 }
7 // some code
8 f ( ) ; // c a l l s the function f defined above
9 }
Hierdurch hat man einen unnamed Namespace verwendet, der einzig und
allein die Aufgabe hat, die Funktion mit dem glorreichen Namen f davor
zu schützen, einer anderen Funktion f in die Quere zu kommen, die an einem
anderen Ort definiert sein könnte. Der Aufruf von f() in Zeile 8 findet
aufgrund der zuvor genannten Auflösungsstrategie sicher zuerst die im Namespace
definierte Funktion f.
Allerdings kann ich zu dieser Vorgehensweise wirklich nur noch sagen,
dass es wohl keinen schlimmeren Hack gibt als solche sinnlosen Funktionsnamen.
Sollte man jemals in die Situation kommen, einen unnamed Namespace
zu brauchen, dann sollte man lieber einmal stark darüber nachdenken, ob
nicht ein Umschreiben des Codes dringend vonnöten wäre. Bei sauber geschriebenem
Code ist die Wahrscheinlichkeit praktisch Null, dass man jemals
unnamed Namespaces brauchen würde. Natürlich kann man jetzt auch das
Argument bringen, dass es ja z.B. alten Code gibt, den man wiederverwenden
möchte und der eben leider einmal nicht so toll ist. Aber auch dann würde
ich sehr dringend (!) zu einer Überarbeitung raten. Durch das Kaschieren
von schlimmen Hacks hat man das Problem ja doch nur verschoben und nicht
aus der Welt geschafft!