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