Modules Design Fehler?



  • Vor längerer Zeit hab ich mal einen Vortrag besucht der mehr oder minder
    diesem Jan/2019 Blog
    https://vector-of-bool.github.io/2019/01/27/modules-doa.html entsprochen
    hat

    Hört sich alles ziemlich fiese an, teilweise ja verworrener als mit
    Includes und definitiv noch schwieriger für Buildsysteme optimal zu
    bauen

    Gab es zu dem import-Name != Datei-Name Problem im Blog Topic
    "A Sisyphean Scanning Task" noch Verbesserungen oder sind die Diskussionen
    abgeschlossen und das ist der finale Stand?

    Ich hab alle follow up Post und die Proposals gelesen, aber
    vielleicht ist jemand noch näher dran und kann noch was zum aktuellen
    Stand sagen

    Allgemein hab ich das Gefühl das es keinen juckt das es in diesen speziellen Teilen sogar schlechter ist als Include-Dateien - keine eindeutige Pfad-Zuordnung mehr möglich wie bei Includes



  • @llm sagte in Modules Design Fehler?:

    keine eindeutige Pfad-Zuordnung mehr möglich wie bei Includes

    So eindeutig sind die ja auch nicht. Und genau wie bei Includepfaden wird man wohl Modulsuchpfade angeben.

    Ich denke es läuft dann auf Modulnamen wie domain.ein.langer.pfad.zum.modul raus.



  • @manni66

    Genau so denken die meisten

    aber das soll so nicht in den Standard kommen, weil:

    1. C++ keine Dateien kennt im Standard - (gibt ja irgendwelche IBM Kisten die keinen hierarchischen Dateisysteme haben)
      Warum ist der Include-Pfad in C++ erlaubt - weil es nicht Teil des C++ Standards ist, sondern eine Preprozessor Extension

    2. Man ja möchte das der module Name anders sein kann als die Datei in der es definiert wird
      d.h. der Name ist kein Bezug mehr zur Implementationsdatei

    3. diese Pfade bisher Teil des Includes waren und dann jetzt wohl extern verwaltet werden müssen
      d.h. also mehr Aufwand und es gibt dazu scheinbar auch keine Proposals noch dazu ist dann an der
      Nutzungstellen nicht mehr klar welchen Code man da sich eigentlich zieht

    und x andere relativ sinnfreien Einschränkungen

    Module haben scheinbar gar nicht das offizielle Ziel die Kompilierzeit stark zu verbessern, das ist nur für
    manche Szenarien (STL, Increment-Build usw.) ein Seiteneffekt - realtiv schwach für eines der größten Probleme der C++ Community (ich rede da von allen C++ Projekten und deren Kompilierzeiten und nicht das kleine Tool vom Fränzchen nebenan)

    und keinen juckts - alle denke "Das wird schon gut"



  • Dieses Forum ist möglicherweise nicht der beste Ort, um solche Bedenken anzubringen. Ich würde mal zum cpplang slack und dort in den #modules Channel gehen. Einladung ggf. unter https://cppalliance.org/slack/.



  • Dieses Forum ist möglicherweise nicht
    der beste Ort, um solche Bedenken anzubringen.

    Die Bedenken sind schon mehrfach angebracht worden - auch von C++Standard nahen Leuten (z.B. Gabriel Dos Reis)
    aber da bewegt sich nicht viel - und die Community ist total passiv in Erwartung der Dinge die da kommen...

    Argument:
    -Das wird schon
    -Mach halt Forward Deklarierung
    -Dein Code ist bestimmt schlecht
    -Die Entscheidungen waren bisher immer gut
    -Die werden das schon so machen wie ich mir das denke

    relativ wenig Grundsatz-Diskussion - der Blog Post ist einer der wenigen die überhaupt zu dem Thema existieren


Anmelden zum Antworten