spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

using namespace ist eigentlich nur da zu verwenden, wo die qualifzierte Angabe zu schlecht lesbar wäre. Niemand möchte so etwas lesen:


Das ist einfach nur unleserlich. Und daher kann man using benutzen, um das ganze ein wenig lesbarer zu machen und den Code nich unnötig aufzublähen. (in Quellform)

Das "böse" daran ist using in einem Header zu benutzen, der jeder includen kann. Das wäre dann gegen den Sinn von namespaces, nämlich dem schützen von Namen. Der Benutzer des Headers hat dann nämlich das Problem, dass alle Bezeichner des Namensraumes ausgeschütter werden und er darf dann das Problem ausbaden.

Daher Faustregel:
Keine using namespace benutzen, erst recht nicht in Headern und in Quelldateien nur dann einsetzen, wenn es zur Lesbarkeit des Codes helfen soll.

Also ich weiß gar nicht was ihr alle gegen using habt. Das ist ein elementares Konzept von namespaces und man sollte es keinesfalls verteufeln.
Letztendlich muss das jeder selbst entscheiden, aber ich benutze es in Headern, wenn ich es mir gut überlegt habe und in cpp Dateien quasi immer. Ich hatte auch noch nicht wirklich viele namespace Probleme, und da ist der Komfort, weniger tippen zu müssen und eine erheblich bessere Übersicht zu haben doch wichtiger.
Alleine schon bei std:: ist es äußerst unwahrscheinlich, das jemand ein cout oder so anbietet. Eine gescheit geschriebene C++ Lib benutzt dann ihren Namespace intern überall (z.b. per using), aber hat kein using in den Headern stehen, die die Benutzer inkludieren und dann hat man auch keinerlei Probleme damit.

Hallo

Also ich habe auch immer using verwendet, aber nie in headern, weil das wirklich zu schwierigen Fehlern fürhen kann. In cpp-Dateien kann man die aber ruhig benutzen.

chrische

Zitat von »"Jonathan_Klein"«

Also ich weiß gar nicht was ihr alle gegen using habt. Das ist ein elementares Konzept von namespaces und man sollte es keinesfalls verteufeln.
Letztendlich muss das jeder selbst entscheiden, aber ich benutze es in Headern, wenn ich es mir gut überlegt habe und in cpp Dateien quasi immer. Ich hatte auch noch nicht wirklich viele namespace Probleme, und da ist der Komfort, weniger tippen zu müssen und eine erheblich bessere Übersicht zu haben doch wichtiger.

Imo sollte die Tipparbeit nie ein Grund für ein pro/contra sein..
Klar ist es recht unwahrscheinlich, dass man Namenskonflikte hat, aber wenn man im Sinne von Erweiterbarkeit denkt, dann kann es ja durchaus sein, dass du mal einen Header irgendwo anderst ebenfalls brauchst und da hast du dann ev. einen Konflikt. Dazu kommt ja noch, dass diese Ausschüttung sich dann auf alles andere ebenfalls ausweitet. Sprich du hast schütest in einem Header aus, welcher in einer anderen Headerdatei included wird und dann gute Nacht.
Das fiese ist daran ja, dass es sehr lange sehr gut geht ohne Probleme, aber WENN du dann mal einen Konflikt hast und du doch alle explizit qualifizieren musst dann viel Spass. Das darst du dann auf sehr vielen Ebenen machen.

Zitat

Alleine schon bei std:: ist es äußerst unwahrscheinlich, das jemand ein cout oder so anbietet. Eine gescheit geschriebene C++ Lib benutzt dann ihren Namespace intern überall (z.b. per using), aber hat kein using in den Headern stehen, die die Benutzer inkludieren und dann hat man auch keinerlei Probleme damit.

Es gibt mehr als nur cout, wie z.B string, vector, list, find, sort usw., welche Namen durchaus auch irgendwo anderst gebraucht werde können und man sich nicht mit einem Alternativ namen begnügen will.

Ich kann dir jetzt kein eigens Erfahrenes Beispiel vor die Augen halten, wo man wegen falschem Benutzen von namespaces Tage lang arbeit hatte reinstecken müssen, aber ich könnte mir das durchaus in einem grösseren Projekt vorstellen.

Was haltet ihr denn z.B. von: ?

Hallo

Klar geht das. Der Sinn ist, dass man nicht den ganzen namespace verfügbar macht, sondern nur dir angegebene Funktion.

chrische

Zitat von »"drakon"«

Imo sollte die Tipparbeit nie ein Grund für ein pro/contra sein..

Doch, finde ich schon. Wenn man mehr tippen muss, wird der Code unübersichtlicher und länger und je mehr man tippt, desto mehr Fehler können potentiell entstehen.
Gut, das ist hier jetzt vielleicht etwas spitzfindig, aber oft ist es halt so, dass die einfachste Lösung die beste ist, also z.B. eine kurze Lösung.

Und es ist auch oft so, dass man sehr genau weiß, welche Bibliotheken man wo einsetzt. Eine echte Gefahr wäre es z.b. wenn man wxWidgets und die Standardlib zugleich benutzen würde, und beide hätten eine Stringklasse. glücklicherweise (oder Dummerweise) haben aber alle wxWidgetsklassen das Präfix wx, also kann ich bequem wxString und string mischen, ohne jedesmal std::string schreiben zu müssen.
Aber wenn man halt die Libs, die man benutzt, kennt, und diese nicht vollkommen dämlich programmiert sind (also z.B. einen eigenen namespace haben) kann man Probleme schon fast ausschließen.
Klar, wenn es mal knallt, kann man richtig lange suchen, aber ich programmiere jetzt schon recht lange und hatte damit wie gesagt noch nie wirklich Probleme und wenn dann, sind sie auch nicht unmöglich zu finden.
Mein Hauptgrund bleibt, dass der Code übersichtlich und angenehmer zu tippen ist. Das ist natürlich irgendwo Subjektiv, aber ich denke, noch schlimmer ist es, generell von using abzuraten. (das ist ähnlich wie bei defines, nur das diese tatsächlich sehr oft eine richtig schlechte Alternative sind, aber es gibt auch Situationen wo sie einem das Leben extrem vereinfachen).

Zitat

Wenn man mehr tippen muss, wird der Code unübersichtlicher und länger und je mehr man tippt, desto mehr Fehler können potentiell entstehen.

Das sind imo 2 verschiedene paar Schuhe. Textlänge und Übersichtlichkeit. Ein Ausdruck kann länger sein und durch das mehr beshreiben, was er macht und von dem her besser verständlich sein. (siehe z.B C Funktionen)
Vor allem ist es Heutzutage keine Tipparbeit mehr dahinter, da man eh nicht mehr als 2-3 Buchstaben für einen Ausdruck tippen muss, wenn man eine anständige IDE hat. Somit sind wir wieder direkt bei der Übersichtlichkeit und das ist auch der Grund, den ich genannt habe, wann man using wirklich braucht.

Ich sehe es eher andersherum. Ich finde den Code deutlich übersichtlicher, wenn ich auf einen Blick sehe, welche Funktion, welches Namespace ich verwende.
Daher verwende ich using namespace so gut wie nie. Meiner Meinung nach macht es ja einen Sinn, dass sich die Funktionen in einem gesonderten Namespace befinden.
Und diese Ordung hebe ich einfach auf, indem ich mit using um mich werfe.
Gut, wenn ich jetzt nur ein using namespace std verwende, ist das jetzt kein Problem, aber chaotisch kann es dann werden, wenn alle möglichen namspaces per using eingebunden werden.
Ich vertrete also die Einstellung, dass ich lieber weiß, welche Funktionen woher aufgerufen werden. Durch using namespace kann Code sehr chaotisch werden. Darum verzichte ich...