spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »dot«

Eine solche using Direktive in einem Header ist eine der wenigen Sachen, von denen praktisch uneingeschränkt abzuraten ist. Einfacher Grund: Nehmen wir an, jemand anderes möchte deinen Code verwenden und inkludiert nichtsahnend deinen Header in seinem Programm. Er hat aber in seinem Programm schon irgendwo anders einen Typ, der den gleichen Namen hat wie irgend ein Typ aus einem der inkludierten Standard Header. Duch das using namespace in deinem Header verpestest du den globalen Namespace mit dem ganzen Inhalt des namespace std und plötzlich funktioniert in dem Programm des nichtsahnenden Users deines Code nichts mehr...

Prinzipiell bin ich deiner Meinung, aber ganz so drastisch ist es dann doch nicht. Zum einen wird der Code von einem durchschnittlichen Hobbyentwickler niemals von jemand anderem benutzt. Und zum anderen ist es echt unwahrscheinlich, dass irgendjemand auf die Idee kommt, seine eigene string-Klasse zu schreiben. Es ist schlimm genug, dass es in Qt sowas wie QString gibt, aber selbst die heißen 'QString' und nicht 'string'. Man muss natürlich unterscheiden, ob man jetzt Anwendungs- oder Bibliothekscode schreibt. Wenn du in deiner Anwendung die Klassen aus der Standardbilbiothek ohnehin überall benutzt (und dagegen gibt es kaum Argumente), dann kann dir mit einem using in einem Header, der von der ganzen Anwendung eingebungen wird trotzdem praktisch nichts passieren - du müsstest schon eine zweite Bibliothek eingebunden haben, die auch eine string-Klasse hat, die entweder in keinem Namespace ist (dann wäre die Bibliothek aber mies, denn Klassen mit solchen Standardnamen gehören nun wirklich in namespaces), oder du hast bei dieser Bibliothek auch using benutzt - dann bist du aber selber Schuld und obendrein bekommst du einen Compilerfehler und kannst an diesen Stellen dann gerade den namespace noch explizit dabei schreiben.
Allgemein halte ich das Problem für weit weniger dramatisch, als viele immer meinen.

Es mag sein, dass man in einem Anfängerprojekt praktisch nie tatsächlich Probleme damit bekommen wird. Aber sobald es etwas komplexer wird, gibts da meiner Erfahrung nach schneller Probleme, als man vielleicht denken mag. Zusätzliche Libraries sind genauso wenig abwegig wie eigene Stringklassen (UTF-8 anyone?) und string ist ja jetzt bei weitem nicht der einzige Name, der im namespace std so zu finden wäre. vector, list, min, max, array, queue, thread, mutex, yield, lock, exception...das sind nicht gerade Namen mit Seltenheitswert...

Abgesehen davon, widerspricht es einfach der Grundidee von Namensräumen, in einem Header, der an allen möglichen Stellen eingebunden werden soll, den globalen Namensraum mit allem möglichen Kram zuzumüllen. Und auch wenn man vielleicht einige Zeit lang damit davonkommt: Wenn es dann auf einmal doch plötzlich eine Namenskollision gibt den ganzen vorhandenen Code auszumisten und anzupassen, ist alles andere als spaßig...

An using Direktiven und Deklarationen in einer .cpp Datei ist imo absolut nichts auszusetzen. Auch in Headern ist beides völlig in Ordnung und sehr praktisch, so lange man es benutzt, um Namen in andere namespaces zu holen etc. Problematisch wird es, sobald der globale Namensraum verpestet wird, das sollte man in Headern imo einfach aus Prinzip schon nicht tun. Nur weil man ganz sicher weiß, dass im Moment dadurch nicht alles sofort in die Luft fliegen wird, ist es noch lange nicht auch gleich eine gute Idee...

Yay, Flamewar! Will mitmachen Namespaces sind generell scheiße, ich verwende ja immer Präfixe, das ist viel besser als jedes mal diese using namespace Scheiße oben in meine Header reinzuschreiben...

Ironie zu erkennen war schon immer eine hohe Kunst der leider nicht jeder gewachsen ist Oh, ich hab natürlich meine Ausrufezeichenrudel vergessen

Zitat von »dot«

Es mag sein, dass man in einem Anfängerprojekt praktisch nie tatsächlich Probleme damit bekommen wird. Aber sobald es etwas komplexer wird, gibts da meiner Erfahrung nach schneller Probleme, als man vielleicht denken mag.

Ok, mit großen, kommerziellen Projekten habe ich noch keine Erfahrung. In den Projekten, wo ich alleiniger Programmierer bin, ist der Code noch relativ übersichtlich und in Uni Projekten hat man sowieso noch ganz andere Probleme, als ein paar usings. Und naja, wenn ich wirklich mal einen Fehler habe weil ich eine neue Bibliothek integriert habe, kann ich mich auch gerade 20 Minuten hinsetzen und den Code kurz umschreiben (ist ja nicht so, dass man groß debuggen müsste, der Compiler sagt einem ja alles).
In großen Projekten mit vielen Programmierern ist man natürlich nicht so flexibel und aus den 20 Minuten kann wohl auch ganz schnell mal mehr werden. Wobei es halt auch letztendlich nicht viel mehr Arbeit ist, in jede cpp noch ein zusätzliches using zu schreiben.
Aber ein Flamewar lohnt hier nicht, einigen wir uns darauf, dass man es nicht tun sollte.