006
16.10.2008, 17:37 Uhr
0xdeadbeef
Gott
(Operator)
|
Es bezeichnet den std-Namensraum (std für Standard). Alle Symbole der Standardbibliothek befinden sich darin.
Namensräume sind im Grunde ziemlich einfach - zum Beispiel:
| C++: |
#include <iostream>
namespace beispiel {
void foo() {
std::cout << "Nur so zum Beispiel." << std::endl;
}
void bar() {
// Kann beispiel::foo() auflösen, weil wir bereits im Namensraum beispiel sind
foo();
}
}
void baz();
int main() {
beispiel::bar(); // oben angegebene bar-Funktion
baz();
}
void baz() {
using beispiel::bar;
bar(); // wegen der using-Direktive jetzt ohne Präfix nutzbar
}
|
Namensräume werden am häufigsten wohl in Bibliotheken verwendet, weil die nachher nicht wissen, mit welchem Code sie kompilieren müssen - es geht dabei stumpf um das Vermeiden von Kollisionen.
Was using-Direktiven angeht, es ist generell am besten, Namensräume explizit anzugeben, oder sich im Falle sehr langer Namensraumnamen Aliase zu definieren, z.B.
| C++: |
namespace fs = boost::filesystem;
fs::path p("/foo/bar"); // Bezeichnet boost::filesystem::path
|
Es ist allerdings möglich, sich Symbole ohne Namensraumpräfix verfügbar zu machen, wie oben mit
| C++: |
using beispiel::bar;
|
Es wäre außerdem möglich,
| C++: |
using namespace beispiel;
|
zu schreiben, was gleich alle Symbole aus dem beispiel-Namensraum verfügbar macht; allerdings muss ich vor letzterer Variante ausdrücklich warnen, weil du mitunter nur schlecht abschätzen kannst, was du dir alles an Implementationsdetails, die mit deinen eigenen Symbolen kollidieren könnten, heranschaffst.
So oder so, wenn du Namensraum-Aliase oder using-Direktiven benutzt, beschränk sie nach Möglichkeit in ihrem Auswirkungsbereich (oben, zum Beispiel, wirkt die using-Direktive nur in baz), und egal was du tust, pack sie nie ins globale Scope einer Headerdatei - sonst übertragen sich diese Probleme auf allen Code, der diese Headerdatei jemals benutzen will.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra |
