spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »wunhopkuendo«

Das mit using std::cout etc. war nur pure faulheit, weil ich mir das ganze umschreiben sparen wollte,
ist es denn sicherer, das std:: vor jedes cout zu schreiben? im Rahmen meines Projektes meine ich, ich weiß ja
was ich uungefähr tun werde, und was ich nicht tun werde, deswegen scheint mir das in diesem Projekt sinnlos..

Ich war ja schon immer ein Verfechter von 'using'. Es ist wie mit allem in C++, man muss Wissen, was es tut und dementsprechend entscheiden, ob man es benutzen sollte, oder nicht.
Es kommt halt stark darauf an, wie und wo man 'using' verwendet. Benutzt man es überhaupt nicht, sind namespaces nicht sehr viel mehr als Präfixe, die man mit hässlichen Doppelpunkten schreiben muss. Die Frage ist halt, ob man nur einzelne Elemente mit using importiert oder gleich alles (using namespace). Und die Frage ist, ob man es lokal tut (innerhalb einer Funktion), in einer Übersetzungseinheit (.cpp Datei) oder in einem Header (.hpp Datei).
Die eigentliche Gefahr ist eben, dass es Namenskollisionen geben kann. Wenn man Glück hat, bekommt man Compilerfehler, wenn man Pech hat, wird die falsche Funktion aufgerufen. Aber solche Kollisionen passieren halt nur, wenn man nicht den Überblick hat, was wo genutzt wird.
Ich persönlich benutze eigentlich IMMER using, es sei denn, es handelt sich um ziemlich generische Namen ('Exception') und ich möchte im Code wirklich klar machen, woher das Element jetzt kommt (boost::exception, std::exception, mycustom::exception etc.). Aber bei Dingen wie string oder cout ist es halt klar, woher die kommen.
Das einzige was ich dann noch überlege ist, auf welcher Ebene das using steht. Es geht dabei auch einfach darum, redundanten Code zu vermeiden. Wenn ich weiß, das etwas eh in JEDE cpp Datei käme, die diesen Header einbindet, dann kommt halt auch ein using in einen Header. Man muss natürlich aufpassen vor indirekten Einbindungen, im Zweifelsfall taucht ein Header an mehr stellen auf, als man denkt.
Was man auf jeden Fall vermeiden sollte, ist eine Bibliothek zu schreiben (ob man sie jetzt selber benutzt, oder nicht), deren Interface dir deinen Namensraum verschmutzt. Besonders schlimm ist in dieser Hinsicht die windows.h, die so nette Dinge wie min/max Makros definiert, die wirklich schrecklich viel ärger machen können.

Versuche dir also einfach klar zu machen, was wo benötigt wird. Je weniger Abhängigkeiten, desto einfacher ist dein Code zu verstehen. Aber gleichzeitig solltest du redundanten Code vermeiden, der führt auch leicht zu Fehlern (wenn man nur eine Stelle ändert) und macht das Programm schwerer lesbar. Versuche also möglichst, das ein Header dir genau das in deinen Namensraum packt, was du auch benutzen möchtest, wenn du diesen Header einbindest.