011
07.01.2008, 22:54 Uhr
0xdeadbeef
Gott
(Operator)
|
Naja, using namespace geht dem, was Namensräume erreichen sollen, völlig zuwider, das ist das grundsätzlichste Problem. Wenn jetzt eine andere Bibliothek das gleiche Symbol verwendet, läufst du damit in Probleme.
Davon abgesehen aber holt using namespace neben den Symbolen, die du brauchst, noch eine ganze Menge mehr in den globalen Namensraum, im Fall von using namespace std; unter anderem Implementierungsdetails der Standardbibliothek - also weißt du im Endeffekt nie genau, wann du in Namenskonflikte laufen kannst.
Die Meinungen gehen etwas auseinander, wenn es um mögliche Anwendungsgebiete von using-Direktiven geht. Allgemeiner Konsens ist, dass using in Headerdateien nichts verloren hat, weil du nie weißt, wo sie nachher mal eingebunden werden. In Source-Dateien sieht man es gelegentlich mal, besser ist allerdings, wenn man sie schon benutzt, sie auf Funktionen zu beschränken, also
| C++: |
int main() {
using namespace std;
...
}
|
Das Problem verschwindet dadurch nicht vollständig, aber zumindest ist sein Wirkungsbereich dadurch eingeschränkt. Etwas besser ist es, die importierten Symbole direkt anzugeben, also
| C++: |
int main() {
using std::cout;
using std::endl;
cout << "Hello, world." << endl;
}
|
Dadurch verschwindet das Problem möglicher Überlappungen mit anderen Bibliotheken zwar auch nicht vollständig, aber zumindest holst du dir keine unbekannten Symbole. Nur kann eine solche Liste mitunter recht lang werden, und du siehst trotz allem nicht auf einen Blick, aus welcher Bibliothek das Symbol denn jetzt kommt.
Ich für meinen Teil bevorzuge es allerdings, die Symbole gleich komplett auszuschreiben, oder bei langen Namensraumnamen namespace aliases zu definieren - zum Beispiel bei boost.filesystem
| C++: |
int main() {
namespace fs = boost::filesystem;
fs::path my_path("/foo/bar"); // fs::path == boost::filesystem::path
}
|
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra |
), also sieht man die Alias-Definition am Anfang der Funktion in aller Regel noch.
