using namespace std VS using std::cin;...

BeNNeR

Kleine Frage am Rande. Ich bin verwirrt wegen diesen beiden Möglichkeiten:

using namespace std

using std::cin;
using std::cout;
//noch viel mehr Anweisungen...

Also ich hab beides schon benutzt, beides geht natürlich Der einzige Unterschied, den ich kenne, ist der, dass es wesentlich bequemer ist, nicht alles einzeln auflisten zu müssen, weswegen ich eigentlich immer die erste Variante benutze. Ich hab mal in der FAQ nachgesehen, aber nichts nützliches gefunden dazu: Kann mir jmd sagen, welche Nachteile es hat, die erste Variante zu benutzen? Es muss ja welche geben, sonst wäre die 2.Variante bestimmt schon ausgestorben...

hagman

Hallo,

bei der ersten Variante sind alle Names aus dem Raum std verfügbar, bei der zweiten nur cin und cout. Bei der ersten Variante können so leichter Namenskonflikte entstehen.

Ich bevorzuge meistens:

std::cout << "Hello" << std::endl;

Siehe dazu: http://fara.cs.uni-potsdam.de/~kaufmann/?page=GenCppFaqs

unter:

Was ist eine using-Direktive?
Was ist eine using-Deklaration?

BeNNeR

Danke für deine Antwort. Ich denk das reicht mir zu, um Vor- und Nachteile zu kennen. Eine kompliziertere Antwort hätte ich eh nicht verstanden
Gibt es denn eine Variante, die häufiger verwendet wird von den beiden? Oder kann man nun allgemein sagen, dass eine "besser" ist als die andere?

hagman

Hallo,

grundsätzlich gilt: keine Namespaces in Headerdateien öffnen. Das ist böse. Wenn jemand dann deine Headerdatei inkludiert, kann er böse Überraschungen erleben in Form von Namenskonflikten.

Am zuverlässigsten ist wohl die direkte Qualifizierung, kann aber bei langen Namespacebezeichnungen zu unschönem Code führen. Dann würde ich eher die Using-Deklaration bevorzugen. Wenn es geht diese dann so lokal wie möglich machen.

BeNNeR

OK. Zum Dank für deine Antwort gibt es noch ein "Danke" -->Das passiert, wenn ich zu lang auf Arbeit sitz und nichts so richtig zu tun habe...
-->Auf die Idee dass es arge Probleme geben kann, wenn der Namespace in einem Header geöffnet wird, bin ich noch gar nicht gekommen, aber leuchtet mir ein

groovemaster

hagman schrieb:

grundsätzlich gilt: keine Namespaces in Headerdateien öffnen. Das ist böse.

Das hört man zwar immer wieder, so pauschal kann man das allerdings nicht sagen, imo. Wie "böse" das Öffnen von Namensräumen in Headerdateien ist, hängt davon ab, wie "public" diese ist.

hagman schrieb:

Am zuverlässigsten ist wohl die direkte Qualifizierung, kann aber bei langen Namespacebezeichnungen zu unschönem Code führen.

Auch dafür gibt es Möglichkeiten, die einem helfen.

namespace a = b::c::d;

Jester

groovemaster schrieb:

hagman schrieb:

grundsätzlich gilt: keine Namespaces in Headerdateien öffnen. Das ist böse.

Das hört man zwar immer wieder, so pauschal kann man das allerdings nicht sagen, imo. Wie "böse" das Öffnen von Namensräumen in Headerdateien ist, hängt davon ab, wie "public" diese ist.

Kannst Du das mal genauer erklären?

Wenn Du im Header nen NS aufbrichst und ich hab in meinem Projekt ne Funktion, die genauso heißt, dann zwingst Du mir ne Funktion auf, die ich nicht haben wollte. Also solltest Du das lassen. Immer. Grundsätzlich.

Oder meintest Du mit "public", daß der Code eben nur privat genutzt wird. In dem Falle kannst Du natürlich tun und lassen was Du willst. Ich muß Deinen Code dann ja nicht benutzen.

groovemaster

Jester schrieb:

Oder meintest Du mit "public", daß der Code eben nur privat genutzt wird. In dem Falle kannst Du natürlich tun und lassen was Du willst. Ich muß Deinen Code dann ja nicht benutzen.

Yep, so war das gemeint.

DrGreenthumb

dann kann man auch sagen #define max(a,b) sei in ordnung, jenachdem wie "public" der code ist.... Aber das war eigentlich noch nie ein Kriterium.

hagman

Hallo,

ich finde es nicht nur böse, sondern auch unnötig. Schlechten Stil sollte man sich nicht angewöhnen.

groovemaster

DrGreenthumb schrieb:

dann kann man auch sagen #define max(a,b) sei in ordnung

Das ist ja wieder eine andere Baustelle. Inline Funktionen vs. function-like Makros? Da ist die Antwort in C++ relativ eindeutig. Und die Definition von Inline Funktionen im globalen Namensraum sehe ich ähnlich wie die using Direktive.

DrGreenthumb schrieb:

jenachdem wie "public" der code ist.... Aber das war eigentlich noch nie ein Kriterium.

Kriterium? Verrate mir doch mal, was bei folgenden Beispielen A und B technisch gesehen der Unterschied ist.

A

// internal.h
using namespace foo;

// form1.cpp
#include "internal.h"

// form2.cpp
#include "internal.h"

B

// form1.cpp
using namespace foo;

// form2.cpp
using namespace foo;

Ich sehe nirgendwo, dass A "böser" ist als B. Entweder sind beide "böse" oder keiner. Und mein Compiler bestätigt mich, denn der sagt mir, dass ÜE's A und ÜE's B identisch sind.
Oder plädierst du für die vollkommene Abschaffung der using Direktive?

und wie siehts aus wenn man NS in .cpp dateien öffnet?

CStoll

Der Unterschied ist ganz einfach - im CPP-File weißt du, welche Bibliotheken du dort mit eingebunden hast. Also kannst du Namenskonflikte sauber eingrenzen. Den Header will eventuell jemand anderes einbinden, da weißt du nicht, ob das "using namespace std;" womöglich einen Konflikt zwischen std::find (du verwendest es nicht, dein "Kunde" benötigt es jedoch für einen anderen Teil des Programms mit dem von dir geschriebenen find() kollidiert).

groovemaster

CStoll schrieb:

Den Header will eventuell jemand anderes einbinden

Nein, will er nicht. Deshalb heisst der Header ja auch internal.h, wird nur in diesem Projekt verwendet und gelangt auch in keine anderen Hände. Jemand anderes soll sich gefälligst seine eigenen Header schreiben.

CStoll

groovemaster schrieb:

Nein, will er nicht. Deshalb heisst der Header ja auch internal.h, wird nur in diesem Projekt verwendet und gelangt auch in keine anderen Hände. Jemand anderes soll sich gefälligst seine eigenen Header schreiben.

Wenn du die Definitionen nur an einer Stelle benötigst, warum brauchst du dann den Header? Header sind normalerweise dafür da, die Schnittstelle deiner Funktionsbibliothek für andere Programme festzulegen.

groovemaster

CStoll schrieb:

Wenn du die Definitionen nur an einer Stelle benötigst, warum brauchst du dann den Header?

Von welcher Definition sprichst du?
So ein Header kann zB dann sinnvoll sein, wenn du in vielen Quellcodedateien immer wieder einige Sachen brauchst, die mit 2-3 Zeilen nicht getan sind. Anderen mag es anders gehen, aber ich hab keine Lust, das jedesmal aufs Neue hinzuschreiben.

CStoll schrieb:

Header sind normalerweise dafür da, die Schnittstelle deiner Funktionsbibliothek für andere Programme festzulegen.

Ne, das ist nur eine Anwendung davon. Header sind vor allem für weniger Schreibaufwand und Codekonsistenz sinnvoll. Theoretisch könnte man auch vollkommen ohne Header programmieren. Nur glaub ich nicht, dass irgendjemand Lust hat, sich jedesmal per Copy&Paste die benötigten Sachen in seine Quellcodedatei zu holen.

Für die lange using-Schleifen kann man sich auch etwas abhelfen ohne den ganzen NS zu öffnen. Ich hab in meinen Bibliotheken dafür nen extra NS, der so aussieht:

namespace UsingStdLibTypes
{
  using Lib::foo;
  using Lib::bar;
  using Lib::blubb;
  using Lib::bla; 
}

So kann der Benutzer einfach using namespace UsingStdLibTypes; schreiben und kann die Standardtypen die man an jeder Ecke braucht direkt verwenden und wenn es Probleme gibt, kann er sich immernoch direkt über den NS verwenden

DrGreenthumb

DrGreenthumb schrieb:

jenachdem wie "public" der code ist.... Aber das war eigentlich noch nie ein Kriterium.

Kriterium?

wie Jester schon sagte, in deinem Code kannst du natürlich alle Schweinereien machen die du willst.

Oder plädierst du für die vollkommene Abschaffung der using Direktive?

nein