using std? = nicht professionell (Umfrage)
-
Ich finde
using namespacegut, v.a. in der cpp-Datei. Die Dateien sind meistens kurz, die Abhängigkeiten klar und es ist unnötig, so viel Extratext zu schreiben. Bei std ist sowieso so gut wie immer klar, worum es geht, da ist das std:: in meinen Augen völlig nutzlos. Und wen bei einer Schnittstelle interessiert, was die Abhängigkeiten sind, kann ja in der Headerdatei nachschauen.
-
Wenn man in einem Modul 100 Klassen hat, die 100 Klassen alle in einer Kompilierungseinheit benötigt, dann will ich den Entwickler sehen, der jedesmal den ewig langen namespace-Namen ausschreibt oder die 100 using Anweisungen am Anfang der Datei einfügt und ihn fragen wofür er bezahlt wird.
-
Mr.Long schrieb:
Wenn man in einem Modul 100 Klassen hat, die 100 Klassen alle in einer Kompilierungseinheit benötigt, dann will ich den Entwickler sehen, der jedesmal den ewig langen namespace-Namen ausschreibt oder die 100 using Anweisungen am Anfang der Datei einfügt und ihn fragen wofür er bezahlt wird.
Wenn du 100 Namespaces mit
using namespacereinholst und dann keine Namenskonflikte bekommst, dann würde ich dich fragen wofür du überhaupt Namespaces verwendest.EDIT: Korrigiert: using =>
using namespace
-
Nathan schrieb:
Drei Buchstaben: A. D. L.
Dass das nötig ist, zeigt, dass an dem System irgendwas nicht richtig ist.oder dass es verdammt richtig ist.
-
hustbaer schrieb:
Mr.Long schrieb:
Wenn man in einem Modul 100 Klassen hat, die 100 Klassen alle in einer Kompilierungseinheit benötigt, dann will ich den Entwickler sehen, der jedesmal den ewig langen namespace-Namen ausschreibt oder die 100 using Anweisungen am Anfang der Datei einfügt und ihn fragen wofür er bezahlt wird.
Wenn du 100 Namespaces mit using reinholst und dann keine Namenskonflikte bekommst, dann würde ich dich fragen wofür du überhaupt Namespaces verwendest.
- seit wann holt man mit using namespaces rein?
- um Namenskonflikte zu vermeiden
-
@Mr.Long
Sorry,using namespace.Also du verwendest Namespaces um Namenskonflikte zu vermeiden, holst dann 100 Namespaces mit
using namespacerein, verwendest Klassen aus diesen 100 Namespaces und bekommst dann trotzdem keine Namenskonflikte.
Sehr interessant.EDIT: Bei "bekommst trotzdem keine Namenskonflikte" meine ich dass du keine "ambiguous name" Fehler beim Kompilieren bekommst.
Nicht Fehler beim Linken o.ä. weil die "fully qualified names" unterschiedlich wären. Letzteres ist natürlich durch die Verwendung von Namespaces sichergestellt, das ist mir schon klar. (Vorausgesetzt die Namespaces der einzelnen Module/Libraries sind alle unterschiedlich, aber das ist sowieso Voraussetzung dafür dass Namespaces überhaupt irgendwas bringen.)
-
otze schrieb:
Nathan schrieb:
Drei Buchstaben: A. D. L.
Dass das nötig ist, zeigt, dass an dem System irgendwas nicht richtig ist.oder dass es verdammt richtig ist.
Nein. ADL ist ein Hack um eine schönere Syntax für Operatoren sowie customization points zu ermöglichen. ADL untergräbt Namespaces.
Das führt dann ggf. zu tollem, ungewollten ADL:#include <vector> namespace N { struct X { }; template<typename T> int* operator+( T , unsigned ) { static int i ; return &i ; /* just to stub in the function body */} } int main() { std::vector<N::X> v(5); v[0] ; }Das ist das klassische Beispiel, was früher unter einigen Compiler/Standardbilbiothekskombination nicht kompilierte. Der Grund ist, dass der operator+ aus N ggf. via ADL gefunden wird und eine bessere Variante ist, als der operator+ für die Iteratoren/Pointer, die intern in vector::operator[] verwendet werden und demzufolge verwendet werden möchte.
Ein "verdammt richtiges" System sieht irgendwie anders aus.
-
aber inwiefern ist das ein Argument für deinen Punkt "Dass das nötig ist, zeigt, dass an dem System irgendwas nicht richtig ist." (hervorhebung von mir). Du argumentierst gegen ADL, nicht dafür, dass es notwendig ist.
-
@Nathan
Ich verstehe nicht ganz wieso ADL ein Hack sein soll.
ADL macht mMn. schon Sinn.
Ohne ADL müsste man tonnenweiseusing/using namespaceschreiben nur um Operatoren verwenden zu können. Fände ich nicht so gut.Das Problem sehe ich weniger bei ADL, sondern eher bei den Overload Resolution Regeln.
Wenn man einen "ambiguous" Fehler bekäme, sobald mögliche Kandidaten in mehreren Namespaces gefunden werden (egal wie "gut" die jeweils besten Kandidaten aus den verschiedenen Namespaces "passen"), wäre das von dir gezeigte Beispiel kein Problem.
Und auf die Schnelle fällt mir auch kein Beispiel ein, wo diese Regel mit vernünftigem Code einen Fehler verursachen würde.Diese Regel nachträglich einzuführen wäre vermutlich trotzdem etwas krass, da u.U. sehr viel "unvernünftiger" Code existiert, der dann auf einmal nicht mehr kompilieren würde.
-
hustbaer schrieb:
@Nathan
Ich verstehe nicht ganz wieso ADL ein Hack sein soll.Weil ADL nachträglich eingefügt wurde und ein Loch in namespaces schafft. namespaces sollten keine Namen freigeben, ADL ist eine nachträgliche Veränderung, die ein Backdoor schafft -> ein Hack.
@otze:
Ok, Missverständnis. In der Hinsicht ist das schon gut, dass ADL nätig wurde,um Namen freizugeben, denn das zeigt, dass das System funktioniert. Allerdings ist das trotzdem nicht ganz richtig, dass das nötig ist, um so grundlegende Features zu unterstützen.
-
Nathan schrieb:
hustbaer schrieb:
@Nathan
Ich verstehe nicht ganz wieso ADL ein Hack sein soll.Weil ADL nachträglich eingefügt wurde und ein Loch in namespaces schafft. namespaces sollten keine Namen freigeben, ADL ist eine nachträgliche Veränderung, die ein Backdoor schafft -> ein Hack.
Ich würde mal behaupten dass das Ansichtssache ist.
-
hustbaer schrieb:
@Mr.Long
Sorry,using namespace.Also du verwendest Namespaces um Namenskonflikte zu vermeiden, holst dann 100 Namespaces mit
using namespacerein, verwendest Klassen aus diesen 100 Namespaces und bekommst dann trotzdem keine Namenskonflikte.
Sehr interessant.EDIT: Bei "bekommst trotzdem keine Namenskonflikte" meine ich dass du keine "ambiguous name" Fehler beim Kompilieren bekommst.
Nicht Fehler beim Linken o.ä. weil die "fully qualified names" unterschiedlich wären. Letzteres ist natürlich durch die Verwendung von Namespaces sichergestellt, das ist mir schon klar. (Vorausgesetzt die Namespaces der einzelnen Module/Libraries sind alle unterschiedlich, aber das ist sowieso Voraussetzung dafür dass Namespaces überhaupt irgendwas bringen.)Ich verstehe nicht was du von mir willst. Vielleicht solltest du mal meine Antwort nochmal durchlesen.
Man kann halt nicht alles haben.
-
Edit: die antwort muss noch verfeinert werden.
-
@Mr.Long
Ja, du hast Recht.
Ich hab mir mal wieder zu wenig Zeit genommen und etwas gelesen was gar nicht dasteht.
Sorry.Ja, wenn du 100 Klassen aus nur einem Namespace brauchst, dann ist
using namespacevermutlich OK. Und wird auch nicht zu Namenskonflikten führen.
-
ich benutze 'using namespace' meist für std::placeholders (EDIT2: Die ja ein wenig aus der Mode sind), C++14 predefined literals und boost krams. EDIT: und eigenes im kleinen scope.
den standard hole ich mir (fast?) nie komplett.
ich habe nichts dagegen std::vector und std::string zu schreiben. Ich finde es auch irgendwie besser lesbar...EDIT3: using namespace XYZ; in einem Header wiederum halte ich für eine Straftat
-
Inwiefern sind std::placeholders aus der Mode?
-
crazyyzarc schrieb:
Hey,
mir wurde erklärt, wiederholte mal erklärt das:
using namespace std;kein professionelles Programmieren ist - was haltet ihr davon? Wie macht ihr das?
Pros verwenden auf keinen Fall using, i++, delete und if-schleifen.
-
ImbaProProgger schrieb:
crazyyzarc schrieb:
Hey,
mir wurde erklärt, wiederholte mal erklärt das:
using namespace std;kein professionelles Programmieren ist - was haltet ihr davon? Wie macht ihr das?
Pros verwenden auf keinen Fall using, i++, delete und if-schleifen.
Nein, das ist wie in der Kirche. Die Pros predigen, diese Dinge niemals nicht zu tun, aber dann tun sie es heimlich doch, wenn keiner zuguckt und reden sich ein, dass sie schließlich verantwortungsvoll damit umgehen können.
-
Du verwendest
delete? Das wirft ja ein ganz neues Licht auf dich
-
Nach meiner Erfahrung ist "using namespace std" sehr professionell. Auch im Header. Im professionellen Bereich wird Code zusammengefrickelt bis es funktioniert. Sollte dann doch mal guter Code in der Produktion landen, wird es so lange kaputt gepflegt, bis niemand Bereit ist, für die kleinste Änderung Verantwortung zu übernehmen. "using namespace std" hilft, Code unwartbar zu machen. Ist keine grosse Hilfe, aber doch ein Schritt in die Richtung.