mikrocontroller.net

Forum: PC-Programmierung Modules Design Fehler?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von cppbert (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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?

von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von cppbert (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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
...Yet, it seems that the wider community still expect modules to be

A name scoping mechanism (they are not)
A replacement to libraries (they are not)
A massive compilation speed improvement (they offer some improvement in some use-cases)
Portable (they are not)
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?

von DPA (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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?

von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Vincent H. (vinci)


Bewertung
0 lesenswert
nicht lesenswert
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.

von cppbert (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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

von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von DPA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Carl D. (jcw2)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Vincent H. (vinci)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von DPA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Carl D. (jcw2)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Carl D. (jcw2)


Bewertung
1 lesenswert
nicht lesenswert
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"

von DPA (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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?

von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.