Softwareentwicklung in C++ - ASC

14. Namespaces 459
tion stehen, also in unserem Fall z.B. in Zeile 15, dann würde sich die Verwendung
von cout ohne Scope Operator auf die main Funktion beschränken.
Spinnt man diesen Gedanken mit der Sichtbarkeit weiter, so kann man
sich leicht vorstellen, dass eine using Direktive, die innerhalb eines Namespaces
steht, für den gesamten Namespace gilt. Dieses Feature wird gerne
verwendet, wenn ein großes Modul mit mehreren kleinen Submodulen arbeitet.
Alle Teile des Namespaces können hierbei auf die Submodule ohne
besonderen Scope zugreifen, die Programmteile, die außerhalb des Namespaces
stehen, aber nicht. Durch diesen Mechanismus kann man sehr gut
gewisse Implementationsdetails vor den Benutzern einer Library verstecken.
Neben der Verwendung von using für einzelne Teile eines Namespaces
gibt es auch noch die Möglichkeit mit einer einzigen Anweisung gleich den
gesamten Namespace sichtbar zu machen. Wollten wir unseren gesamten
Namespace Datastructures_ sichtbar machen, würden wir Folgendes schreiben:
using namespace Datastructures_;
Damit wären alle Elemente aus unserem Namespace ohne expliziten Scope
ansprechbar. Ich möchte jedoch darauf hinweisen, dass diese Vorgehensweise
wirklich nur in besonderen Fällen sinnvoll ist. Im Normalfall ist es besser, einzelne
Elemente aus einzelnen Namespaces einzubinden um Überraschungen
zu verhindern. Es könnte ja sein, dass in einem Namespace gewisse Elemente
enthalten sind, die eigentlich nur für den privaten Gebrauch innerhalb der
Implementation dieses Namespaces gedacht sind. Mir ist schon klar, dass
das eigentlich nur aufgrund von eher mangelhaftem Design von Namespaces
passieren kann, aber man soll niemanden in Versuchung führen :-).
Es gibt auch noch einen anderen Grund, warum man nicht gleich ganze
Namespaces automatisch sichtbar machen soll: Was passiert, wenn in zwei
Namespaces zufällig Elemente unter demselben Namen existieren? Dann
kann sich der Compiler beim Aufruf ohne Scope nicht wirklich entscheiden,
welches Element denn nun gemeint ist. In einem solchen Fall wird man also
dann erst recht wieder gezwungen, mit einem expliziten Scope zu arbeiten,
um den Compiler zu beruhigen.
Einen Fall allerdings gibt es, in dem der Compiler einen Name-Clash selbst
auflöst: Nehmen wir an, wir hätten in unserem Namespace Datastructures_
die Direktive
using namespace SomeStacks_;
und im Namespace SomeStacks_ hätten wir, so wie in Datastructures_, eine
Funktion doSomething mit denselben Parametern. Ruft man in einem Codestück
innerhalb des Namespaces Datastructures_ nun doSomething auf,
so wird automatisch die Implementation aus dem eigenen Namespace genommen
und nicht die sichtbar gemachte Implementation aus SomeStacks_.
Aus gutem Grund möchte ich allen Lesern raten, die Bezeichner von
Namespaces immer sprechend und nicht zu kurz zu machen. Namespaces
mit Bezeichnern wie z.B. DS (für Datastructures_) sind um jeden Preis