Das eine Projekt verwendete einen Namespace (sagen wir "Abc"), in dem aller Code dieses Projekts liegen musste, sofern es nicht ausnahmsweise besser war (etwa bei operator<<(std::ostream &, const T &) ) den globalen Namespace zu verwenden. Innerhalb von Abc gab es dann für jedes logische Modul des Projekts einen weiteren Namespace, also z.B. Abc::Database, Abc::Model, Abc::Gui, Abc::Aux usw. Alle Fach-Klassen mussten denselben Namen tragen und wurden nur über den Namespace unterschieden, also Abc::Database::Person (für die Tabelle), Abc::Model::Person, Abc::Gui::Person (für den Dialog) usw.

In dem anderen Projekt wurde nur ein Namespace für das Projekt verwendet; es gab keine weiteren Namespaces innerhalb von Abc. (Ok, noch extremer wäre es, alles in den globalen Namespace zu legen. Aber so weit wollten wir dann doch nicht gehen) Die Fach-Klassen wurden über Präfixe unterschieden: DBPerson, MdlPerson, DlgPerson usw. Die Präfixe wurden vorher vereinbart.

Was haltet ihr davon? Welche Vor- und Nachteile seht ihr? Was verwendet ihr also in euren Projekten - sofern man euch lässt?

Stefan.

Bei mir fangen desweiteren Namspaces immer mit Kleinbuchstaben an, Klassen mit Großbuchstaben.
Z.B.:
abc::database::Person.
Das erleichtert einem ziemlich das Erkennen im Code.
Außerdem macht es das möglich, freie Funktionen die zu einer Klasse gehören in einen passenden namespace zu legen, ohne Konflikte zwischen Klasse/Namespace zu bekommen, wenn man das nicht als static member-Funktion implementieren will.

Natürlich nur in Projekten einer gewissen Größe, so dass Namespaces (theoretisch) Sinn machen.

Warum nur in Projekten bestimmter Größe? Ich benutze immer Namespaces, selbst wenn es nur ein kleines Tool ist. Außnahme sind wirklich nur helloworlds, dummys, prototypen u.ä. Also alles was eh weg geschmissen wird.

Meine Namespace-Ebenen sind sehr flach. D.h. ich habe nur abc:: . Eine Ebene tiefer gehe ich nur für Ausnahmefälle, z.B. um zu verdeutlichen, das es sich um einen sehr speziellen Bereich handelt. Für gewöhnlich progge ich nur Platformneutral. Wenn ich aber weiß "Oh, jetzt brauch ich hardcore Win32-Code!", dann mache ich in dem Fall abc::win32:: . 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.

Wenn man zu viele Ebenen hat, wird der Code nicht übersichtlicher und lesbarer. Ich überlege mir dann lieber z.B. für die erste Ebene andere Namen, z.B. abc:: und xyz:: . Man muß da halt kreativ sein.

Was ich auch nicht leiden kann, sind zu lange Namespace-Namen. Dann soll lieber ein Klassen- oder Funktionsname aussagekräftig sein. Davon habe ich mehr Vorteile in der Wartung.

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.

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.

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 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.

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 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.

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.

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...

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".

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).

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.