using std? = nicht professionell (Umfrage)

otze

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.

JulianH

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

hustbaer

@Mr.Long
Sorry, using namespace .

Also du verwendest Namespaces um Namenskonflikte zu vermeiden, holst dann 100 Namespaces mit using namespace rein, 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.)

Nathan

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.

otze

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.

hustbaer

@Nathan
Ich verstehe nicht ganz wieso ADL ein Hack sein soll.
ADL macht mMn. schon Sinn.
Ohne ADL müsste man tonnenweise using/using namespace schreiben 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.

Nathan

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.

hustbaer

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.

JulianH

hustbaer schrieb:

@Mr.Long
Sorry, using namespace .

Also du verwendest Namespaces um Namenskonflikte zu vermeiden, holst dann 100 Namespaces mit using namespace rein, 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.

Columbo

Edit: die antwort muss noch verfeinert werden.

hustbaer

@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 namespace vermutlich OK. Und wird auch nicht zu Namenskonflikten führen.

5cript

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

Columbo

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.

SeppJ

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

tntnet

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.

cooky451

AntiSepp schrieb:

Du verwendest delete ? Das wirft ja ein ganz neues Licht auf dich

Ne, er verwendet es ja nur im Dunkeln.

Bei kurzen namespaces wie "std", "sf" oder vielleicht auch "OpelPopel", die nicht über eine gewisse Wortlänge hinausreichen und nicht unübersichtlich sind, würde ich nie using namespace benutzen.
Bei bibliotheken wie z.B. Boost, wo es lange namespaces gibt, benutze ich es hingegen.

camper

Trampeltier schrieb:

Bei bibliotheken wie z.B. Boost, wo es lange namespaces gibt, benutze ich es hingegen.

Dafür sind allerdings namespace aliase da.