std::

Th

Kleine Berichtigung.
Um einzelne Namen in den globalen Namesraum einzubinden:

using std::cout; // no 'namespace'

Im Header sollte man niemals 'using namespace ...' benutzen, und in den Sourcedateien ist es Geschmackssache (bzw. Tipparbeit -).

Also bedeuet das, dass man in jeder datei nur einmal namespace benutzen sollte ???

außer in headerfiles

*john 0

ubernoob schrieb:

Also bedeuet das, dass man in jeder datei nur einmal namespace benutzen sollte ???

Nein, aber Du solltest nach Möglichkeit "using namespace XYZ" gar nicht verwenden. Qualifizierung von Namen ist nur mehr Tipparbeit hat sonst aber keinerlei negative Auswirkungen. Das benutzen von Nichtqualifizierten Bezeichnern hingegen führt zu Doppeldeutigkeiten und Überdeckungseffekten.

Ja, aber wenn man nur einen Namensraum verwendet gibts doch keinen Überdeckungseffekt, und ich verwende nur den Namespace std. War mir aber nicht sicher ob man nicht doch mehrere verwenden kann, hat sich aber jetzt erledigt, thx

Simon2

ubernoob schrieb:

Ja, aber wenn man nur einen Namensraum verwendet gibts doch keinen Überdeckungseffekt, und ich verwende nur den Namespace std....

Ja ... aber das bedeutet, er nutzt alles aus diesem Namensraum - und das ist eine ganze Menge !!
All das kann mit Namen kollidieren, die Du selbst deklarieren oder wo anders her importieren willst.
Da man sogar nachträglich alles Mögliche in den namespace importieren kann, wird's noch komplexer:

namespace std {
   void SimonsFunktion() { }
   void openGLDraw() {}
   void directXdraw() {}
}
// Hoppla, jetzt sind diese Funktionen ebenfalls im Namensraum std.

... sprich: Nicht tun.

Gruß,

Simon2.

*john 0

ubernoob schrieb:

Ja, aber wenn man nur einen Namensraum verwendet gibts doch keinen Überdeckungseffekt, und ich verwende nur den Namespace std.

std ist fürs Beschreiben Tabu! Du blendest via "using namenspace std" "std" in den globalen Namensraums ein. In diesem globalen Namensraum tummeln sich alle C-Libraries etc. Die Gefahr, daß es hierbei zu Namenskollisionen oder Überdeckungseffekten der "std" Objekte kommt ist extrem groß. Wenn Du eigenen Library Projekte oder Komponenten entwirfst, solltest Du sie in einen eigenen Namensraum ablegen, dadurch verhinderst Du Namenskollisionen. Ich weiß auch nicht warum bei vielen C++-Programmieren so eine Abneigung gegen Namensräume existiert, sachlich gibt es bei neuen Projekten dafür keinen Grund.

namespace ubernoon {
  namespace projektx {
     class Foo {
     };
  }
}

Konrad Rudolph

~john schrieb:

ubernoob schrieb:

Also bedeuet das, dass man in jeder datei nur einmal namespace benutzen sollte ???

Nein, aber Du solltest nach Möglichkeit "using namespace XYZ" gar nicht verwenden. Qualifizierung von Namen ist nur mehr Tipparbeit hat sonst aber keinerlei negative Auswirkungen. Das benutzen von Nichtqualifizierten Bezeichnern hingegen führt zu Doppeldeutigkeiten und Überdeckungseffekten.

Ach was. In Implementierungsdateien ist das doch alles irrelevant, denn hier sollte man überschauen können, welche Symbole verfügbar sind bzw. sich eventuell überdecken.

Und überall vollqualifizierte Bandwurmbezeichner zu verwenden ist für die Lesbarkeit auch nicht gerade das beste. Im Gegenteil: C++ ist sowieso meist schon ziemlich komplex, da muss man nicht auch noch vollqualifizierte Namen verwenden, wenn es sich auch vermeiden lässt.

*john 0

Konrad Rudolph schrieb:

Ach was. In Implementierungsdateien ist das doch alles irrelevant, denn hier sollte man überschauen können, welche Symbole verfügbar sind bzw. sich eventuell überdecken.

Es verschlechtert die Lesbarkeit des Codes, und macht damit die Softwarewartung aufwendiger. Wenn man "vector<int>" liest, denkt doch jeder an "std::vector<int>" und nicht an "john::vector<int>" oder gar "::vector<int>".

*john 0

Ach ja: so etwas ist ja auch möglich

// Header Datei
namespace john {
namespace std {
  template <typename T>
  class vector {
  ...
  };
}}

// CC Datei
#include "my_header.h"

using namespace john;

int main {
  std::vector<int> v;
}

Konrad Rudolph

~john schrieb:

Konrad Rudolph schrieb:

Ach was. In Implementierungsdateien ist das doch alles irrelevant, denn hier sollte man überschauen können, welche Symbole verfügbar sind bzw. sich eventuell überdecken.

Es verschlechtert die Lesbarkeit des Codes, und macht damit die Softwarewartung aufwendiger. Wenn man "vector<int>" liest, denkt doch jeder an "std::vector<int>" und nicht an "john::vector<int>" oder gar "::vector<int>".

Nö. Wer es nicht schafft, kontextabhängig zu denken, hat eh verloren. Wenn ich in einem Linear-Algebra-Code mit einem nicht näher qualifizierten Vektor arbeite, dann erwarte ich natürlich, dass das ein algebraischer Vektor ist und kein 'std::vector'. Und wenn ich gerade einen Wrapper für die 3rd-Party-Bibliothek „john“ schreibe, dann erwarte ich natürlich einen 'john::vector'.