Warum wird "using namespace std;" als schlechte Praxis angesehen?

Question

Ich habe von anderen gehört, dass das Schreiben using namespace std; im Code falsch ist, und dass ich Folgendes verwenden sollte std::cout y std::cin stattdessen direkt.

Warum ist using namespace std; eine schlechte Praxis? Ist es ineffizient oder besteht die Gefahr, dass mehrdeutige Variablen deklariert werden (Variablen, die denselben Namen haben wie eine Funktion in std Namespace)? Wirkt sich das auf die Leistung aus?

Answer 1

Dies hat nichts mit der Leistung zu tun. Aber bedenken Sie Folgendes: Sie verwenden zwei Bibliotheken namens Foo und Bar:

using namespace foo;
using namespace bar;

Alles funktioniert einwandfrei, und Sie können die Blah() von Foo und Quux() von Bar ohne Probleme. Aber eines Tages aktualisieren Sie auf eine neue Version von Foo 2.0, die nun eine Funktion namens Quux() . Jetzt haben Sie einen Konflikt: Sowohl Foo 2.0 als auch Bar importieren Quux() in Ihren globalen Namespace. Es wird einige Mühe kosten, dies zu beheben, insbesondere wenn die Funktionsparameter übereinstimmen.

Hätten Sie die foo::Blah() y bar::Quux() , dann die Einführung von foo::Quux() wäre ein Nicht-Ereignis gewesen.

Answer 2

Ich bin mit allem einverstanden Greg schrieb aber ich möchte noch etwas hinzufügen: Es kann sogar noch schlimmer kommen, als Greg gesagt hat!

Die Bibliothek Foo 2.0 könnte eine Funktion einführen, Quux() die eindeutig besser zu einigen Ihrer Aufrufe an Quux() als die bar::Quux() Ihr Code wird seit Jahren aufgerufen. Dann wird Ihr Code lässt sich noch kompilieren aber ruft er stillschweigend die falsche Funktion auf und tut Gott-weiß-was. Schlimmer kann es nicht mehr werden.

Beachten Sie, dass die std Namespace hat eine Vielzahl von Bezeichnern, von denen viele sehr gemeinsame (denken Sie an list , sort , string , iterator usw.), die mit großer Wahrscheinlichkeit auch in anderem Code vorkommen.

Wenn Sie dies für unwahrscheinlich halten: Es gab eine gestellte Frage hier auf Stack Overflow, wo so ziemlich genau das passiert ist (falsche Funktion aufgerufen aufgrund von ausgelassenen std:: Präfix), etwa ein halbes Jahr nachdem ich diese Antwort gegeben habe. Ici ist ein weiteres, jüngeres Beispiel für eine solche Frage. Dies ist also ein echtes Problem.

---

Hier ist ein weiterer Datenpunkt: Vor vielen, vielen Jahren habe ich es auch als lästig empfunden, allem aus der Standardbibliothek das Präfix std:: . Dann arbeitete ich an einem Projekt, bei dem zu Beginn beschlossen wurde, dass beide using Direktiven und Deklarationen sind verboten, außer für Funktionsbereiche. Und nun raten Sie mal! Die meisten von uns brauchten nur wenige Wochen, um sich an die Schreibweise des Präfixes zu gewöhnen, und nach ein paar weiteren Wochen waren sich die meisten von uns sogar einig, dass der Code dadurch tatsächlich besser wurde besser lesbar . Dafür gibt es einen Grund: Ob man kürzere oder längere Prosa mag, ist subjektiv, aber die Präfixe tragen objektiv zur Klarheit des Codes bei. Nicht nur für den Compiler, sondern auch für Sie ist es einfacher zu erkennen, auf welchen Bezeichner er sich bezieht.

Innerhalb eines Jahrzehnts wuchs dieses Projekt auf mehrere Millionen Codezeilen an. Da diese Diskussionen immer wieder auftauchen, war ich einmal neugierig, wie oft der (erlaubte) Funktionsumfang using tatsächlich in dem Projekt verwendet wurde. Ich habe die Quellen danach durchsucht und nur ein oder zwei Dutzend Stellen gefunden, an denen es verwendet wurde. Für mich ist das ein Hinweis darauf, dass Entwickler, wenn sie es einmal ausprobiert haben, nicht finden std:: schmerzhaft genug, um die Verwendung von Richtlinien auch nur alle 100 kLoC zuzulassen, selbst dort, wo die Verwendung erlaubt war.

---

Unterm Strich: Alles explizit voranzustellen schadet nicht, ist sehr gewöhnungsbedürftig und hat objektive Vorteile. Insbesondere macht es den Code für den Compiler und den menschlichen Leser leichter zu interpretieren - und das sollte wohl das Hauptziel beim Schreiben von Code sein.

Answer 3

Das Problem bei der Umsetzung using namespace in den Header-Dateien Ihrer Klassen ist, dass es jeden, der Ihre Klassen benutzen will (indem er Ihre Header-Dateien einbezieht), dazu zwingt, auch diese anderen Namensräume zu "benutzen" (d.h. alles in ihnen zu sehen).

Es steht Ihnen jedoch frei, eine using-Anweisung in Ihre (privaten) *.cpp-Dateien einzufügen.

---

Beachten Sie, dass einige Leute nicht damit einverstanden sind, dass ich "sich frei fühlen" so sage - denn obwohl ein using Anweisung in einer cpp-Datei ist besser als in einem Header (weil es die Leute, die Ihre Header-Datei einbinden, nicht beeinträchtigt), denken sie, dass es immer noch nicht gut (denn je nach Code könnte es die Implementierung der Klasse schwieriger machen, sie zu pflegen). Dieser C++ Super-FAQ-Eintrag sagt,

Die using-Anweisung existiert für alten C++-Code und um den Übergang zu Namespaces zu erleichtern, aber Sie sollten sie wahrscheinlich nicht regelmäßig verwenden, zumindest nicht in Ihrem neuen C++-Code.

In den FAQ werden zwei Alternativen vorgeschlagen:

• Eine using-Deklaration:

  using std::cout; // a using-declaration lets you use cout without qualification
  cout << "Values:";

• Geben Sie einfach std: ein:

  std::cout << "Values:";

Answer 4

Kürzlich stieß ich auf eine Beschwerde über Visual Studio 2010 . Es stellte sich heraus, dass so gut wie alle Quelldateien diese beiden Zeilen enthielten:

using namespace std;
using namespace boost;

Eine Vielzahl von Boost Features gehen in den C++0x-Standard über, und Visual Studio 2010 verfügt über viele C++0x-Features, sodass diese Programme plötzlich nicht mehr kompiliert werden konnten.

Daher ist die Vermeidung von using namespace X; ist eine Form der Zukunftssicherung, ein Weg, um sicherzustellen, dass eine Änderung an den verwendeten Bibliotheken und/oder Header-Dateien ein Programm nicht kaputt macht.

Answer 5

Kurzversion: Verwenden Sie keine globalen using Deklarationen oder Direktiven in Header-Dateien. Es steht Ihnen frei, sie in Implementierungsdateien zu verwenden. So sieht es aus Herb Sutter y Andrei Alexandrescu zu diesem Thema zu sagen haben in C++-Codierungsstandards (die Hervorhebungen stammen von mir):

Zusammenfassung

Die Verwendung von Namensräumen dient Ihrer Bequemlichkeit und nicht dazu, sie anderen aufzudrängen: Schreiben Sie niemals eine using-Deklaration oder eine using-Anweisung vor einer #include-Anweisung.

Korollarisch: Schreiben Sie in Header-Dateien nicht auf Namespace-Ebene, indem Sie Direktiven oder Deklarationen verwenden; stattdessen sollten Sie alle Namen explizit auf Namespace-Ebene qualifizieren. (Die zweite Regel folgt aus der ersten, weil Header nie wissen können, welche anderen Header #includes nach ihnen erscheinen könnten).

Discusión

Kurz gesagt: Sie können und sollten Namespace using-Deklarationen und Direktiven in Ihren Implementierungsdateien nach #include-Direktiven großzügig verwenden und sich dabei gut fühlen. Trotz wiederholter gegenteiliger Behauptungen sind Deklarationen und Direktiven zur Verwendung von Namespaces nichts Böses und sie vereiteln nicht den Zweck von Namespaces. Vielmehr sind sie es, die Namespaces nutzbar machen .