spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Die merken dann nicht, dass z.B. cin im namespace std liegt und eröffnen früher oder später einen Thread mit dem Titel "Compiler findet cin nicht." oder so ähnlich

Richtig, NachoMan. Ohne dieses using lässt sich das erst einmal leichter verstehen, wenn man sagt: Okay, es gibt Namensräume. In diesen verschiedenen "namespaces" liegen die verschiedenen Objekte. Man greift auf diese zu in dem man das namespace gefolgt von :: und dem Objekt schreibt. Ein Beispiel wäre std::cout, wobei std das namespace ist und cout das eigentliche Objekt. Ein Objekt kann eine Variable, eine Funktion, ein Stream oder vergleichbares sein.

Dass cout eine Funktion ist, das ist mir neu. Damit meinst du hoffentlich, dass man auf den Stream zugreifen kann. Als Grundformulierung wäre es wohl angebracht zu sagen, dass man sagt, dass man auf das jeweilige Objekt dadurch im Namensraum Zugriff bekommt.
Doch using kann für Anfänger auch noch auf andere Weise gefährlich sein. Mal ein simples Beispiel:

Wahrscheinlich wird derjenige sich wundern, wieso er denn nicht auf den Integer im Namensraum sss zugreifen kann, stattdessen die zuvor erstellte Variable mit dem Wert 6 ausgegeben wird.

MfG
Check

Dann wird sich derjenige aber auch über eine Menge anderer Dinge wundern.

Das lokalere Namen globalere überschreiben ist einfach so und hat erstmal nichts mit Namensräumen zu tun. Ansich versucht man ja alles so lokal wie möglich zu halten, und wer in einer solche Funktion den Überblick verloren hat, dass er a noch einmal neu definiert hat, der hat halt schlecht programmiert.

Ich bin grundsätzlich für using, zumindest in Source Dateien.. Ohne das, hat man durch die :: nur zusätzliche Tipparbeit und im Gegensatz zu einfachen Präfixen nur sehr wenig gewonnen. Eine einzelne Sourcedatei ist meist lokal genug, dass keine Namenskonflikte auftreten, und selbst wenn, kann man ja den Namespace imemr noch explizit davor schreiben. Ging mir zum Beispiel mal so, als ich stl und ticpp benutzt habe, die halt beide eine Exception Klasse haben.
In Header muss man natürlich aufpassen. Gerade in Bibliotheken, sollte man es fast immer sein lassen. Aber wenn man in seinem Spiel konsequent STL-Container und ähnliches benutzt, dann schadet es echt nicht, in den Headern, die nur von anderen Spielheadern eingebunden werden zum Beispiel mal ein using std oder boost zu schreiben. So Häufig sind Namenskonflikte jetzt auch nicht, und wenn man doch einen hat, merkt man es in der Regel direkt.

Using gehört zum Namespace Konzept fest dazu und das ist auch gut so. Es ist einfach ein weitere Sprachmittel, man muss eben wissen, wofür es gut ist, und wo man aufpassen muss. Das ist das selbe, wie mit globalen Objekten, die sind auch nicht per se böse, nur halt oft nicht der beste Weg. Aber cout ist auch ein globales Objekt und das ist auch gut so. Man kann natürlich Anfangen und alles durch sinnlose Singletons kapseln, dann hat man kein globales Objekt mehr, aber man hat keinen der Nachteile von globalen Objekten beseitigt und die Sache nur unnötig kompliziert gemacht.

Ein using ist für Anfänger meiner Meinung nach gar nicht verkehrt. C++ ist eben eine komplexe Sprache und egal wie man es dreht oder wendet, zumindest ein wenig muss man eben über namespaces gelesen haben. Früher oder später kennt man dann auch die Details und vorher hat man keine so großen Projekte, dass direkt zig Namenskollisionen auftauchen werden.

Namespaces (inklusiv using) sind ein mächtiges Werkzeug, und mit Macht muss man verantwortungsvoll umgehen. Irgendwelche pauschalen Regeln aufzustellen, ist für Anfänger evtl. eien Orientierung, aber man sollte diese Regeln vergessen, sobald man den Sinn dahinter verstanden hat und ab dann das tun, was in der jeweiligen Situation angebracht ist.

Zitat von »Jonathan_Klein«

Ich bin grundsätzlich für using, zumindest in Source Dateien..

Ja, in .cpp Files ist nichts dagegen einzuwenden, in Headern sollte man das aber auf jeden Fall sein lassen, zumindest using directives (using namespace).

Zitat von »Jonathan_Klein«

Aber wenn man in seinem Spiel konsequent STL-Container und ähnliches benutzt, dann schadet es echt nicht, in den Headern, die nur von anderen Spielheadern eingebunden werden zum Beispiel mal ein using std oder boost zu schreiben. So Häufig sind Namenskonflikte jetzt auch nicht, und wenn man doch einen hat, merkt man es in der Regel direkt.

Auch wenn ich in Headern immer voll qualifizierte Namen verwenden würde, so gibt es immer noch die Möglichkeit, über eine using declaration nur einen einzelnen Namen hereinzuholen, z.B.:

Das ist einer using directive vor allem in einem Header auf jeden Fall vorzuziehen.

Zitat von »Jonathan_Klein«

Man kann natürlich Anfangen und alles durch sinnlose Singletons kapseln, dann hat man kein globales Objekt mehr, aber man hat keinen der Nachteile von globalen Objekten beseitigt und die Sache nur unnötig kompliziert gemacht.

Natürlich hat man dann noch ein globales Objekt, wär ja nicht so als ob Singleton irgendwas dran ändern würd, dafür ists ja auch nicht gedacht, aber das ist ein andres Thema...

Danke Checkmateing, das war ein Flüchtigkeitsfehler. Korrigiert.