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?
Und ja 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
In der Diskussion mit anderen C++ Entwickler bestätigt sich immer wieder das die meisten C++ Entwickler einfach darauf hoffen das alles gut wird also relativ passen zu dem Statement http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1427r0.pdf
1 | ...Yet, it seems that the wider community still expect modules to be |
2 | |
3 | A name scoping mechanism (they are not) |
4 | A replacement to libraries (they are not) |
5 | A massive compilation speed improvement (they offer some improvement in some use-cases) |
6 | Portable (they are not) |
7 | A symbol versioning system (they are not) |
und sich scheinbar nur 5-6 Leute überhaupt intensiv mit dem Thema beschäftigen - obwohl Module mit Abstand die Größte Neuerung wird in der Geschichte von C++ Speziell die (möglichweise, falsch interpretierte) Ignoranz der ganzen Build-Problematik lässt mich schaudern - es fühlt sich so an als wenn die Leute die jahrenlang die Header hoch gehalten haben und einfach nicht bereit waren den nächsten Schritt zu gehen jetzt stark daran beteiligt sind die sich neue ergebenen Schwächen einfach unter den Tisch zu kehren Eure Meinung?
Nun, was soll man dazu sagen? Die header, stellen APIs dar, die .cpp Dateien die implementation. Das erscheint aber halt als "Unpraktisch", dass nicht alles in die selbe Datei zu packen zu können. Und die Anungslosen, die nicht verstanden haben, wozu das gut war, haben die Module halt nicht als Ersatz der Header entworfen, sondern die aus der Implementation generiert, und jetzt hat man den Salat. Als nächstes wird man sicher einen Packetmanager, wie z.B. cargo benötigen, um Abhängigkeiten aufzulösen, make alleine wird's nicht mehr tun. Dann übernimmt C++ die Probleme, die Nodejs (npm), Rust (cargo), Python (pip), etc. schon haben, die Abhängigkeiten der Programme werden Explodieren. Die Packetmanager werden gerade nach und nach von Microsoft aufgekauft, erst grad vor kurzem haben sie sich NPM einverleibt. Wer weiss, vielleicht ist dass ja die Absicht hinter dem ganzen? Vielleicht will jemand die Kontrolle über das C++ Ökosystem?
DPA schrieb: > Nun, was soll man dazu sagen? Die header, stellen APIs dar, die .cpp > Dateien die implementation. Das erscheint aber halt als "Unpraktisch", > dass nicht alles in die selbe Datei zu packen zu können. Und die > Anungslosen, die nicht verstanden haben, wozu das gut war, haben die > Module halt nicht als Ersatz der Header entworfen, sondern die aus der > Implementation generiert, und jetzt hat man den Salat. Es ist doch noch viel schlimmer - Header sind (gewollt) kein richtiger C++ Standard sondern eine Preprozessor Feature durch die Module kommen alle Themen die bisher in C++ auf Preprozessor , Kompiler und Linker verteilt sind - also alle die die keinem gemeinsamen Standard angehören auf einen Punkt zusammen Prepozessor: Er kennt im Gegensatz zu C++ wirklich "Includedateien" und schafft damit die Möglichkeit "public" APIs zu beschreiben - C++ hat davon absolut keine Ahnung Kompiler: Versteht keine Includes, nur forward-Deklarationen - Templates werden ja genauso einfach vom Preprozessor rein kopiert Linker: Dieser schaut nur ob die externen Verweise zwischen den ihm vorgeworfenen obj-Dateien erfüllt werden und erzeugt daraus ein Exe oder Dll-Image Das größte Problem das sich daraus ergibt: -Header Include Orgien bei Templates - bestest Beispiel die STL oder eben Produkttiv-Code der viele Templates nutzt z.B. Eigen, Boost etc. selbst im aktuellen VS2019 noch 73 Includes nur für einen std::vector https://godbolt.org/z/NVcxdT Ich habe Eigen/Boost/STL Projekte analysiert die includieren bis zu 3500 Dateien per cpp - alles 3rd-Party und keiner hat nur einen Hauch von Ahnung wie schlimm das teilweise ist Pesudo Lösung ohne Standard und auch definitiv nicht unproblematisch: Precompile Headers Modules sind jetzt eine Kombination aus Include, und Cpp und da C++ keine Dateien kennen möchte ist so was wie bei C#,Java,D usw. mit Datei-Hierarchien im Import nicht gewollt dazu stehen in eine Modules-Datei noch mehrer Modules - was die ganze Sache noch mal schwieriger macht Die Build-Systeme werden dadurch noch komplizierter !!! Ich hab ehrlich gesagt keine Idee wie diese Selbsteinschränkungen + die gewollte Flexibilität zu irgendwas sinnvollen führen soll und drum herum sitzt die C++ Community und wartet gemütlich...
Es gibt wohl auch nur eine handvolle Leute auf der Welt die wirklich beurteilen können was am Proposal gut oder schlecht ist. Die paar Talks die ich bisher dazu gesehen hab hinterließen bei mir einen ziemlich komplizierten Eindruck... import module module import import export export import . : Das fühlt sich weniger wie ein Feature an als wie eine neue Sprache.
DPA schrieb: > , Rust (cargo) ich verstehe jetzt nicht wirklich was bei Rust die Probleme damit sein sollen - sieht doch ganz ok aus, oder? https://doc.rust-lang.org/reference/items/modules.html
Vincent H. schrieb: > Es gibt wohl auch nur eine handvolle Leute auf der Welt die wirklich > beurteilen können was am Proposal gut oder schlecht ist. Ist auch mein Gefühl
cppbert schrieb: > DPA schrieb: >> , Rust (cargo) > > ich verstehe jetzt nicht wirklich was bei Rust die Probleme damit > sein sollen - sieht doch ganz ok aus, oder Das eigentliche Problem bei Rust ist auch nicht Rust, sondern Cargo. Das haben von anfang an fast alle genutzt, deshalb bekommen die rust Programme schnell recht viele Abhängigkeiten, wie bei anderen Sprachen, die einen Packetmanager haben, auch. Im moment kommt man bei C++ noch ohne Paketmanager aus und hat auch keinen offiziellen, aber falls sich das nach dem modules zeug ändert...
Das schöne an der "don't break existing code" Philosophie von Bjarne ist, man muß das neue nicht benutzen, wenn man es nicht mag.
Carl D. schrieb: > Das schöne an der "don't break existing code" Philosophie von Bjarne > ist, man muß das neue nicht benutzen, wenn man es nicht mag. Ja es is nur deppat wenn Jahr(zehnt)e lang an einer Totgeburt gearbeitet wurd. Schad um die Zeit vieler kluger Köpfe.
Carl D. schrieb: > Das schöne an der "don't break existing code" Philosophie von > Bjarne ist, man muß das neue nicht benutzen, wenn man es nicht mag. Und was passiert, wenn eine Library, die man nutzt, plötzlich module braucht?
Vincent H. schrieb: > Carl D. schrieb: >> Das schöne an der "don't break existing code" Philosophie von Bjarne >> ist, man muß das neue nicht benutzen, wenn man es nicht mag. > > Ja es is nur deppat wenn Jahr(zehnt)e lang an einer Totgeburt gearbeitet > wurd. Schad um die Zeit vieler kluger Köpfe. 5-6 wurden oben erwähnt, wenn überhaupt. Nicht jeder der Papiere schreibt, die vor der potentiellen Nichtmehrnotwendigkeit ihrer Tools warnen, sollte dazugerechnet werden. Einfach abwarten bis/ob es wird.
DPA schrieb: > Carl D. schrieb: >> Das schöne an der "don't break existing code" Philosophie von >> Bjarne ist, man muß das neue nicht benutzen, wenn man es nicht mag. > > Und was passiert, wenn eine Library, die man nutzt, plötzlich module > braucht? Das dürfte eins der zu lösenden Probleme sein. Denn: "don't break existing code"
Wenn eine Library anfängt, Module zu nutzen, ist das doch kein existierender, sondern neuer Code. Die alte Version der Library würde natürlich weiter funktionieren. Aber wer würde schon veralteten, nichtmehr supporteten, Code weiterverwenden?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.