Verwendung von Namespaces in eigenen Projekten

pumuckl

DStefan schrieb:

sofern es nicht ausnahmsweise besser war (etwa bei operator<<(std::ostream &, const T &) ) den globalen Namespace zu verwenden.

Warum sollte es dort besser sein, den globalen Namespace zu verwenden? Wenn du den op<< im selben Namespace wie T deklarierst und definierst, wird er immer gefunden (Koenig-Lookup), egal von wo aus er aufgerufen wird.

namespace foo
{
  class T;
  std::ostream& operator<<(std::ostream& os, T const& t) {/*...*/}
}

namespace bar
{
  void bla
  {
    foo::T t;
    cout << t; //funktioniert, da durch Koenig-Lookup für Funktionen mit T auch in T's namespace foo gesucht wird
  }
}

Artchi schrieb:

Aber das ist schon echt das höchste der Gefühle, was die Ebenenanzahl bei mir angeht. Wenns noch mehr werden soll. Muß man mich schon überzeugen.

Durch viele Ebenen wirds nicht unbedingt unübersichtlicher im Code. Wenn ich in einem Namespace foo einen Unternamespace bar einrichte, dann meist nur um die Elemente von bar in foo zu benutzen, nicht auf höherer Ebene. Und der Namespace baz innerhalb von bar wird auch nur von bar-Elementen benutzt. Daher wird nie jeman foo::bar::baz::X schreiben müssen.

Artchi

pumuckl schrieb:

Durch viele Ebenen wirds nicht unbedingt unübersichtlicher im Code. Wenn ich in einem Namespace foo einen Unternamespace bar einrichte, dann meist nur um die Elemente von bar in foo zu benutzen, nicht auf höherer Ebene. Und der Namespace baz innerhalb von bar wird auch nur von bar-Elementen benutzt. Daher wird nie jeman foo::bar::baz::X schreiben müssen.

Ja, wenn sich das vermeiden lässt, ist das i.O. Aber das ist halt selten der Fall, weil manche halt einfach nach Kategorien aufteilen.
z.B. foo::gfx und foo::snd, da habe ich bei der Benutzung garantiert regelmäßig die volle Schreibweise. Wobei diese zwei Ebenen wirklich noch erträglich sind.

DStefan

klabauter schrieb:

Das zweite ist unschöner aber sicherer.
Denn beim ersten kommt man ziemlich in Konflikte bei nem using namespace...;

Für mich ist das eher ein Grund using namespace nicht zu verwenden. Das kommt bei mir nicht vor. Unter keinen Umständen.

Die Verwendung von Präfixes statt Namespaces ist allerdings weniger Schreibarbeit.

Stefan.

DStefan

pumuckl schrieb:

DStefan schrieb:

sofern es nicht ausnahmsweise besser war (etwa bei operator<<(std::ostream &, const T &) ) den globalen Namespace zu verwenden.

Warum sollte es dort besser sein, den globalen Namespace zu verwenden? Wenn du den op<< im selben Namespace wie T deklarierst und definierst, wird er immer gefunden (Koenig-Lookup), egal von wo aus er aufgerufen wird.

Außer, der Code muss (auch) für so 'ne alte Karre wie VC6 funktionieren. Kommt leider noch immer vor.

Stefan.

DStefan schrieb:

Für mich ist das eher ein Grund using namespace nicht zu verwenden. Das kommt bei mir nicht vor. Unter keinen Umständen.

So lange das ein geschlossenes Projekt ist, ist es ja in Ordnung. Aber lass das mal ne lib werden, die andere User verwenden. Gute Nacht
Ich denke das war mit ein Grund, warum Qt von v2->v3 den namespace Qt:: abgeschafft haben und ihre Klassen nur noch mit nem Präfix versehen

class MainWindow : public Qt::MainWindow
{ /// };

// dann wird das wo verwendet:

#include MainWindow.h
using namespace Qt;
///...
MainWindow win; // welches MainWIndow ist das jetzt?

DStefan

klabauter schrieb:

DStefan schrieb:

Für mich ist das eher ein Grund using namespace nicht zu verwenden. Das kommt bei mir nicht vor. Unter keinen Umständen.

So lange das ein geschlossenes Projekt ist, ist es ja in Ordnung. Aber lass das mal ne lib werden, die andere User verwenden. Gute Nacht
Ich denke das war mit ein Grund, warum Qt von v2->v3 den namespace Qt:: abgeschafft haben und ihre Klassen nur noch mit nem Präfix versehen
class MainWindow : public Qt::MainWindow
{ /// };

// dann wird das wo verwendet:

#include MainWindow.h
using namespace Qt;
///...
MainWindow win; // welches MainWIndow ist das jetzt?

Also für mich ist das eher ein Beispiel dafür, warum using namespace "böse" ist.

Spannender finde ich folgendes Beispiel:

namespace Foo {

class MainWindow {

protected:
   MainWindow(int id);
};

}   // namespace Foo

class MainWindow: public Foo::MainWindow {

public:
   MainWindow()
      : Foo::MainWindow(1)   // <<< Hier britzelt's
   {
   }
};

Mindestens zwei meiner Compiler (mehr hab ich nicht damit konfrontiert) kriegen hierbei nen dicken Hals.
Man muss sich mit einem typedef behelfen:

class MainWindow: public Foo::MainWindow {

   typedef Foo::MainWindow Base;

public:
   MainWindow()
      : Base(1)
   {
   }
};

Bloß was folgt daraus? Soll man besser keinen Namespace verwenden oder ist derjenige einfach ein Idiot, der für die Unterklasse denselben Namen wie die Oberklasse verwendet?

Ich meine übrigens, dass eine Library unbedingt in einem Namespace liegen sollte. In Qt nur Präfixes zu verwenden, ist für mich eine Fehlentscheidung.

Stefan.

pumuckl

DStefan schrieb:

Bloß was folgt daraus? Soll man besser keinen Namespace verwenden oder ist derjenige einfach ein Idiot, der für die Unterklasse denselben Namen wie die Oberklasse verwendet?

Letzteres In Ausnahmefällen kann man auch getrost auf den typedef zurückgreifen, wenns wirklich mal sinnfrei ist sich einen anderen Namen auszudenken (weils keinen passenderen gibt).

Ich meine übrigens, dass eine Library unbedingt in einem Namespace liegen sollte. In Qt nur Präfixes zu verwenden, ist für mich eine Fehlentscheidung.

Absolut. Den Namespace durch einen Präfix zu ersetzen ist ein Schritt nach hinten in die C-Zeiten wo sowas üblich war. Beim Tippen ist der Unterschied vernachlässigbar, ob man nun QT::Wurst oder QT_Wurst schreibt. Der Präfix nimmt dem Entwickler dafür die Möglichkeit, eine (vernünftig gewählte, räumlich beschränkte) using-Direktive zu nutzen.

DStefan schrieb:

Also für mich ist das eher ein Beispiel dafür, warum using namespace "böse" ist.

Argh, das mein ich doch auch!
Nur kannst du nicht verhindern, dass $UNERFAHRENER_USER das nicht macht
Aber im Eneffekt bist ja du eh nicht der böse, wenn der User Stuss baut, denn dein Lib selber kompiliert, egal was der User treibt.
Nur musst du dich evtl. bei gleichen Klassennamen in verschiedenen namspaces auf einige lustige SUpportanfragen einstellen

DStefan schrieb:

Bloß was folgt daraus? Soll man besser keinen Namespace verwenden oder ist derjenige einfach ein Idiot, der für die Unterklasse denselben Namen wie die Oberklasse verwendet?

Ich meine übrigens, dass eine Library unbedingt in einem Namespace liegen sollte. In Qt nur Präfixes zu verwenden, ist für mich eine Fehlentscheidung.

namespace ist die einzige richtige Entscheidung, denke ich auch. Und in der Doku darauf hinweisen using namespace abc::database doch bleiben zu lassen...

pumuckl

DStefan schrieb:

Außer, der Code muss (auch) für so 'ne alte Karre wie VC6 funktionieren. Kommt leider noch immer vor.

Naja... Wenn ich explizit FORTRAN77 schreiben soll, kann ich die Features von FORTRAN90 nicht allesamt nutzen. Wenn ich K&R-C schreiben soll kann ich mit C99 Sprachfeatures Probleme bekommen. Und wenn ich für den VC6 Compiler programmiere darfs eben kein Standard-C++ sein...
Man mag sich jetzt streiten ab wann man einen Compiler als standardkonform bezeichnen darf (95% der Features? 99%? 100% wird wohl kaum einer schaffen), aber der VC6 gehört mit Sicherheit nicht dazu. Und da es sich hier im Forum nunmal um Standard-C++ dreht halte ich es für unnütz, bei jeder zweiten Problemlösung einen Disclaimer dranzuschreiben "es sei denn du benutzt den uralt-Compiler von XY, dann musst du Workaround ZZ01 benutzen".

Artchi

Wer benutzt denn freiwillig VC6, außer er hat ein solch altes VC6-Projekt, das er aus irgendwelchen ominösen Gründen nicht auf einen aktuellen Standard portieren kann?
Das im Standard-C++-Forum überhaupt der VC6 erwähnung findet, grenzt schon an Blasphemie! Holt Eure Mistgabeln raus!

asc

pumuckl schrieb:

DStefan schrieb:

Außer, der Code muss (auch) für so 'ne alte Karre wie VC6 funktionieren. Kommt leider noch immer vor.

...Man mag sich jetzt streiten ab wann man einen Compiler als standardkonform bezeichnen darf (...100% wird wohl kaum einer schaffen),...

100% schafft soviel ich weiß der Comeau (oder er ist zumindest sehr nah dran).

DStefan

Artchi schrieb:

Wer benutzt denn freiwillig VC6, außer er hat ein solch altes VC6-Projekt, das er aus irgendwelchen ominösen Gründen nicht auf einen aktuellen Standard portieren kann?

Tja, ist vielleicht nicht so selten, wie man glaubt. Und die Gründe sind gar nicht so ominös: Ein größeres Projekt zu portieren kostet eine Menge Zeit und Geld. Da geht's dann einfach nach dem Motto "Wieso? Es funktioniert doch!"

Gerade diesen Monat habe ich mich bei einer (durchaus ernst zu nehmenden) Software-Firma beworben, die VC6 noch immer verwendet. Einfach weil sie Schnittstellen einer Fremdfirma verwenden müssen, die in VC6-C++ geschrieben sind.

Das im Standard-C++-Forum überhaupt der VC6 erwähnung findet, grenzt schon an Blasphemie! Holt Eure Mistgabeln raus!

Ich entschuldige mich ausdrücklich für diesen Affront! Hoffentlich ist niemand beim Lesen ernsthaft krank geworden!

Stefan.