Ein paar Gedanken zu namespaces in Projekten



  • Hi,

    ich würde gerne mal eure Meinung zu meiner aktuellen Projektgestaltung hören.

    Unterschiedliche Header- und Quellcodedateien im Projekt fasse ich gerne mit namespaces zusammen (so weit nichts Besonderes). Dabei halte ich es wie boost, sodass ich Ordnerstrukturen habe und jeder Ordner einem namespace entspricht.

    Eine Datei /ui/controller/NiceController.h enthält beispielsweise eine Klasse NiceController im namespace controller, der wiederum im namespace ui liegt.

    Wenn ich Header einbinde, mache ich das dann durch:
    #include <ui/controller/NiceController.h>
    Ich bin also unabhängig von relativen Pfaden.

    So weit bin ich damit zufrieden. Was mir jetzt jedoch häufiger passiert ist: Ich ändere solche namespace-Strukturen, weil ich sie beispielsweise in tiefere Ebenen schiebe oder auch eine Ebene herauf und umbenenne etc.

    Lange habe ich überlegt, welche Lösung dafür gut wäre. Beispielsweise wäre denkbar zu schreiben:

    // BEGIN NAMESPACE TOP
    namespace xy
    {
    namespace zw
    {
    // END NAMESPACE TOP
    

    und einen Textparser zu schreiben, der zwischen BEGIN und END immer die namespaces einfügt, die der Ordnerstruktur entsprechen. Dann kann man schnell mal einen Ordner woanders hinschieben und der namespace ändert sich mit.

    Das gefällt mir zwar sehr gut, jedoch müsste man dafür erstmal so einen Textparser haben, war mir also zu aufwendig.

    Meine neuste Idee, die ich jetzt auch so umgesetzt habe, ist, dass ich am Anfang einfach schreibe:
    #include "namespaceStart.h"
    und am Ende der Datei:
    #include "namespaceEnd.h"

    Dann brauche ich nur für jeden Ordner diese zwei Dateien anlegen und sie beim Verschieben des Ordners kurz ändern. Das erspart bei 10+ Dateien in einem namespace viel Arbeit.

    Wie handhabt ihr diese namespace-Geschichten in größeren Projekten?

    Viele Grüße
    Eisflamme



  • Ich finde namespaces in eigenen Projekten weitgehend nutzlos. Erst recht, wenn man ein namespace pro Verzeichnis macht, das ist ja völlig übertrieben. Wir arbeiten an einem echt riesigen Projekt und setzen namespaces sehr sporadisch ein. Und ich vermisse die überhaupt nicht.
    Wenn es nicht ständig zu Namenskonflikten kommt, sind namespaces doch nur Overhead. Und wieso sollte es innerhalb eines Projekts großartig zu Namenskonflikten kommen?



  • Das ist für manche Abhängigkeitstools nützlich. Da sieht man dann ob namespace1 irgendwie von namespace2 abhängt. Wenn alles im globalen namespace liegt, ist das schon schwieriger. Ist natürlich ein Mangel vom Tool, wenn man so will.

    Strukturiert ihr dann einfach über die Ordner oder wie packt ihr Quell/Headerdateien in größere logische Einheiten? Ich nehme an, es liegen nicht alle Dateien bei euch einfach in einem großen Ordner im globalen namespace.



  • Mechanics schrieb:

    Und wieso sollte es innerhalb eines Projekts großartig zu Namenskonflikten kommen?

    Es kommt nicht zu Konflikten, weil der Namespacename "zu Fuß" in die Klassen-, Funktions- uns sonstwas Namen eigebaut wird.



  • Na ja, das trifft bei mir nicht mal zu. QT braucht meines Wissens eindeutige Namen, zumindest für moc-Objekte, denn die haben ja keinen namespace-Namen im Dateinamen.

    Das betrifft dann natürlich auch nur den QT-Teil der Applikation. Aber nehmen wir mal an, dass die Namen auch ohne namespaces eindeutig sind.



  • manni66 schrieb:

    Mechanics schrieb:

    Und wieso sollte es innerhalb eines Projekts großartig zu Namenskonflikten kommen?

    Es kommt nicht zu Konflikten, weil der Namespacename "zu Fuß" in die Klassen-, Funktions- uns sonstwas Namen eigebaut wird.

    Ja, und das find ich auch ok. Wenn ich eine Klasse "Options" schreiben will und merke, dass es schon eine Options Klasse gibt, dann wähl ich halt einen sprechenderen Namen, z.B. "DocumentOptions". Das kann man sich eh besser merken, als dass er irgendwo eine options Klasse gibt, aber ob das jetzt document::options, oder dom::options, oder mesh::options oder was auch immer war, weißt man wegen using namespace dann eh nicht mehr so genau. Und dann schreibt man irgendwo eine kleine "namespaceübergreifende" Klasse, die etwas macht und muss dann vielleicht 20 Namespaces zusammensuchen, wo was war.



  • Und auf diese Frage?

    Strukturiert ihr dann einfach über die Ordner oder wie packt ihr Quell/Headerdateien in größere logische Einheiten? Ich nehme an, es liegen nicht alle Dateien bei euch einfach in einem großen Ordner im globalen namespace.

    Und eine Anschlussfrage:
    Würdest du dann sagen, namespaces sind weitestgehend nutzlos für eigene Projekte, die standalone sind, machen jedoch bei libraries mehr Sinn? Wenn ich mir boost anschaue, gibt es dort ja viele namespaces, da sind die Bezeichner (ohne namespace) jedoch auch extrem kurz und weisen daher mehr Namenskonflikte auf.

    Wenn ich jetzt z.B. MVC bei mir umsetze, sind Namen aber extrem speziell, da ergibt es dann eben weniger Sinn, das verstehe ich dann schon eher.



  • Wir strukturieren über "Projekte" (im Endeffekt Dlls) und Ordner. Wobei wir selten tiefe Verschachtelungen haben, meist nur eine Ebene, seltener 2-3.
    Was jetzt nicht unbedingt heißen muss, dass wir "gut" strukturieren. Ich versteh deinen Wunsch, Abhängigkeiten zwischen Namespaces zu untersuchen schon. Unser System ist insgesamt nicht gut strukturiert. Die zentralen Dlls sind sehr groß und die können auch nicht mehr auseinandergezogen werden, weil da zu viele Abhängigkeiten sind. Das ist problematisch, wenn wir mal ein "kleines" Tool anbieten wollen, das eigentlich nicht viel macht, aber von einer 20MB Dll abhängig ist. Aber ich glaube nicht, dass es an namespaces liegt. Das Projekt ist halt so gewachsen. Die Blöcke sind oft ziemlich groß und evtl. performancekritisch und es nicht immer von vornherein klar, wie sich das alles entwickelt. Dann hat man irgendwann einen großen Block A und will noch einen Block B schreiben und dann fügt man in A Abhängigkeiten auf B ein, obwohl das auf dem Papier erstmal nicht unbedingt nötig wäre. Und Jahre später ist Block B dann halt auch schon sehr groß und man denkt sich vielleicht, ich will doch eigentlich nur Block A, warum sind die jetzt verflochten... Aber das hat nichts damit zu tun, ob man namespaces verwendet oder nicht. Das sind bewußte Designentscheidungen oder Designfehler.

    Eisflamme schrieb:

    Würdest du dann sagen, namespaces sind weitestgehend nutzlos für eigene Projekte, die standalone sind, machen jedoch bei libraries mehr Sinn?

    Bei libraries find ich namespaces auf jeden Fall sinnvoll. Wenn eine Library eine Klasse wie "String" oder "Map" ohne namespace definieren würde, würde mich das stören. Inwiefern die eigenen Projekte standalone sind, ist wieder so eine Frage... Unser Projekt ist schon sehr groß (rund 14000 Klassen) und wird seit über 20 Jahren entwickelt. Einige von den Komponenten könnte man durchaus als Library ansehen. Bei den Low Level Bibliotheken hätte ich auch keine Bedenken, die in namespaces zu stecken. Aber wenn, dann schon die komplette Bibliothek in einen namespace und nicht pro Verzeichnis. Aber irgendwelche Probleme hatten wir da noch nie und ich seh da jetzt auch keinen Vorteil.
    Ist übrigens nur meine subjektive Meinung und ich hätt auch kein Problem mit anderen Lösungen. Wenn ich eine Firma kommen würde, die seit 20 Jahren für jedes Verzeichnis einen eigenen namespace vergibt, dann würde ich das halt auch so machen. Nur sinnvoll finde ich das nicht.



  • Danke für den ausführlichen Beitrag!

    Für mich ziehe ich den Schluss, dass sich halt wirklich die Frage stellt, was man zusätzlich zu Namenskonflikt-Vermeidung mit namespaces erreichen möchte. Wenn die Ordner bereits strukturgebend sind, man diese als "Packages" betrachtet und dann Abhängigkeiten zwischen Packages betrachten möchte, kann man das auch ohne namespaces machen.

    Nur wie gesagt: Manche Tools arbeiten genau auf dieser namespace-Ebene. Dann ist es meines Erachtens definitiv sinnvoll auch namespaces pro Ordner zu haben. Das ist zurzeit für mich jedoch auch der einzige Grund meine eigene Software so zu gestalten. Dort Teile rauszunehmen und in anderen Projekten einzusetzen ist nämlich ein durchaus realistisches Szenario, so auch schon passiert und unnötige Abhängigkeiten sieht man auf die Weise einfach richtig schnell.

    Hat noch jemand anderes hier Impressionen?



  • Eisflamme schrieb:

    Hat noch jemand anderes hier Impressionen?

    Sei faul und verschiebe das "Problem"
    - bis Du diese Tools einsetzt,
    - bis eine Fremdlib mit Dir kollidiert,
    - bis MSVC irgendein spezielles Standardfeature kann,
    - bis Dein Compiler von selber SSE benutzt,
    - bis…

    Sei nicht proaktiv und hype mit, sondern kümmere Dich um Deine Kunden und Deine Algos.

    Und
    - setze keine Eintagsfliegentools ein,
    - templatisiere nicht jeden kleinen kack,
    - höre nicht auf Pessimisten wie mich,
    - nimm Abstand von jeder "Wunderwaffe",
    - …



  • Das geht in die Richtung, in die mich auch mehr fortbewegen möchte. Gut 🙂


Anmelden zum Antworten