Namensräume
-
Hallo,
ich stelle mir eben die Frage was Namesnräume eigentlich für einen Sinn machen.
Abgesehen von anonymen Namensräumen, sehe ich keinen Grund nicht lieber einfach ein Kürzel vor Namen zu schreiben.class guiFenster {...}; guiFenster fenster;
class gui::Fenster {...]; gui::Fenster fenster;Was bringt mir da potentiell ein Namensraum außer mehr Schreibarbeit?
Vielen Dank für Eure Gedanken!
-
Fitzcarraldo schrieb:
Hallo,
Was bringt mir da potentiell ein Namensraum außer mehr Schreibarbeit?
Vielen Dank für Eure Gedanken!
mehr schreibarbeit?
also einmal ein
namespace gui { //1000fuinktionen und variablen }und 1000x vor jede variable oder funktion gui zu pinseln, würde dein argument entkräften
-
Das ist doch wohl sogar der Hauptgrund weshalb Namensräume eingeführt wurden. Der Ein großer Vorteil ist doch, wenn man am Anfang der Datei entsprechende usings hinstellt hat man letztendlich sogar eine kürzere Schreibweise, da muss man eventuell gar nicht gui:: schreiben muss, sondern nur noch Fenster.
Außerdem kann man so Namenskonflikten leichter vorbeugen. Wenn es im globalen Namensraum 2x Fenster gibt, könntest du ein Problem kriegen. Normalerweise benutzt man nämlich nicht nur Gui als Namespacenamen, sondern packt diesen noch zusätzlich in einen Namespace der den Namen des Frameworks oder der Bibliothek trägt. Dadurch sollte dann eigentlich nicht mehr so schnell ein Namenskonflikt auftreten.Greetz
-
Also die Begründung Schreibarbeit ist mir bisher noch nie in den Sinn gekommen. Aber jetzt wo es angesprochen wird, liegt ich vor Lachen beinahe unterm Tisch. Genial!
using gui::Frame; Frame f; Frame f2; Frame f3; // usw.Ohen Namespace:
guiFrame f; guiFrame f2; guiFrame f3; // usw.Hem, also wenn ich ein ganzes Projekt entwickel, habe ich mit einem using oder using namespace wirklich weniger Schreibarbeit. Es summiert sich letztendlich.
Aber hauptsächlich empfand ich Namespace nicht als weniger Schreibarbeit (interessantes Argument!) sondern vorallem als schöner.
BoostThread t1; BoostMutex m;Ich muß nicht in einem großen Projekt alle paar Zeilen "Boost" lesen. Ich benutze ja meistens etwas aus einem favorisierten Namespace und das steht dann auch in der using-Anweisung. Sollte es mal was doppeldeuttiges sein, schreibe ich einfach den Namespace explizit davor und gut. In den obigen Beispiel sehe ich immer den Vendor einer Klasse oder Funktion. Nervig!!!

-
kann mich meinen vorrednern nur anschliessen,
schreibarbeit kann man mit namensräumen übel sparen.
auch noch son ding:
wenn man mal ne bibliothek austauschen will reichts dann aus nur den namespace zu ändern,
man muß also nich alle klassen löschen/umschreiben sondern kann sie sauber austauschen mit den gleichen namen.
der einzige nachteil aber glaub ich kein muß:
in headern sollte man kein using verwenden, da muß mann das "gui::" dann vor die variable.. setzen,
ist dadurch aber schön übersichtlich.
Soweit ich weiß, kann man in einer übersetzungeinheit sogar mehrere usings verwenden(von oben nach unten), je nach bedarf der funktion. D.h. du kannst für jede definition einer funktion einen anderen namensraum verwenden.
mfg
-
Du kannst ohne Problem zwischen namespaces wechseln, auch innerhalb einer Funktion. Meistens macht man es aber so, das man eines default benutzt und Ausreisser benennt:
void foo() { using namespace boost; shared_ptr p; // aus einem anderen Namespace: std::tr1::shared_ptr p1; shared_ptr p3; // aus boost! }Keine Konflikte und es wird das passende rausgesucht.