C++ Modules

Programmiersprachen, APIs, Bibliotheken, Open Source Engines, Debugging, Quellcode Fehler und alles was mit praktischer Programmierung zu tun hat.
Specialist
Establishment
Beiträge: 124
Registriert: 29.08.2003, 14:22
Kontaktdaten:

Re: C++ Modules

Beitrag von Specialist »

Ich habe es tatsächlich geschafft meine Mathe-Lib auf C++-Modules umzustellen. Das hat mich zusätzlich zur Vorbereitungszeit (Rumspielen mit und Lernen der Modules) nun einen guten Nachmittag und Abend gekostet für eine hand voll Dateien - wie ihr gleich sehen werdet.

Wie war es vorher?
Ein Namespace BSMath, der diverse Klassen und Funktionen enthalten hat. Jede Klasse hatte eine Header und eine CPP inkl. umhschließendem ifndef-define-endif Konstrukt um doppelte Inkludierungen zu vermeiden. Die Klassen wurden innerhalb der Lib gegenseitig verwendet, z.B. hat Matrix von Vector4 Gebraucht gemacht und Triangle von Vector3 etc.

Wie sollte es nach dem Umbau sein?
Es sollte ein Modul BSMath geben, das alle Klassen zur Verfügung stellt. Zusätzlich dazu sollte jede Klasse ein eigenes Submodul bilden, so dass man nicht unbedingt die ganze Bibliothek importieren muss, sondern die Wahl hat. Später könnte man dann ggfs. auch zugehörige Klassen in sinnvollere Submodule aufteilen, z.B. Vector und Matrix in ein Modul stecken, statt beide einzeln zu haben oder Geometrieobjekte in ein Submodul packen, wie Triangle, Plane, etc. Für den Anfang sollte aber alles erstmal einzeln sein, möglichst nah an der Ausgangssituation mit den klassischen Headern.

Projekteinstellungen:
Bevor wir die Modules nutzen können, sind zwei Projekteinstellungen im VisualStudio-Projekt nötig:
C/C++ => Sprache => C++-Sprachstandard: Vorschau - Features aus dem aktuellen C++ Arbeitsentwurf (/std:c++latest)
C/C++ => Erweitert => Alle Quellen auf Modulabhängigkeiten überprüfen: Ja

Aufbau der des Moduls BSMath:
Eine Datei Math.ixx mit folgendem Code:

Code: Alles auswählen

export module BSMath; // Modul definieren und exportieren, damit es per "import BSMath" genutzt werden kann

// Hier kommt der Inhalt des Moduls, der lediglich daraus besteht alle Submodule nach außen "durchzureichen"
export import BSMath.AABB;
export import BSMath.Base;
export import BSMath.Frustum;
export import BSMath.Matrix;
export import BSMath.Noise;
export import BSMath.Plane;
export import BSMath.Quaternion;
export import BSMath.RandomFloat;
export import BSMath.Sphere;
export import BSMath.Triangle;
export import BSMath.Vector2;
export import BSMath.Vector3;
export import BSMath.Vector4;
Die einzelnen Submodule sind alle analog aufgebaut. Als Beispiel hier der Aufbau von AABB:
AABB.ixx

Code: Alles auswählen

export module BSMath.AABB; // Submodul definieren und exportieren

// Nötige andere Module importieren
import BSMath.Vector3;
import BSMath.Frustum;

// Der Namespace wird absichtlich nicht exportiert, da ich mir die Möglichkeit offen halten möchte
// Strukturen zu definieren, die von außen nicht sichtbar sind, Stichwort Visibility/Reachability
namespace BSMath
{
	// Klasse definieren und exportieren nicht vergessen
	export class AABB
	{
	public:
		Vector3 middle, min, max, corner[8];
		void create(Vector3*, Vector3*);
		bool isVisible(Frustum&);
		bool pointInside(Vector3*);
		bool aabbInside(AABB*);
		bool collision(AABB*);
	};
}
Ich habe mich bewusst dazu entschieden den Weg zu gehen, die Implementierungen nach wie vor getrennt von den Interfaces zu halten. Mir gefällt das Konzept, weil man so einen schnellen Überblick über das Klasseninterface bekommt, ohne sich durch die ewig lange Implementierung wühlen zu müssen. Es sei aber jedem freigestellt die Implementierung auch direkt in der Modulinterfacedatei (ixx) zu machen. Für kleine Funktionssammlungen bietet sich das definitiv an.
Ergo gibt es zu der AABB.ixx auch eine passenden AABB.cpp:

Code: Alles auswählen

// Definition unseres Submoduls
// Achtung: hier kein export! Wir wollen dem Compiler nur mitteilen, dass diese Datei zum Modul BSMath.AABB gehört.
// Wer möchte, kann so die Implementierungen sogar auf mehrere CPPs aufteilen.
module BSMath.AABB;

// Nötige Importe von anderen Submodulen
import BSMath.Vector3;
import BSMath.Frustum;

// Unser Namespace mit den Implemtnierungen - kein Hexenwerk und auch kein Modulzeugs mehr ab hier
namespace BSMath
{
	// Implementierungen der Methoden (ich verzichte hier aus Platzgründen auf den eigentlichen Code)
	void AABB::create(Vector3* minimum, Vector3* maximum)
	{
	}

	bool AABB::isVisible(Frustum& viewfrustum)
	{
	}

	bool AABB::pointInside(Vector3* point)
	{
	}

	bool AABB::aabbInside(AABB* aabb)
	{
	}

	bool BSMath::AABB::collision(AABB* aabb)
	{
	}
Zur Vollständigkeit der Beispiele hier noch die Base.ixx, die eine kleine Sammlung an Funktionen darstellt, die sonst nirgends eingeordnet sind:

Code: Alles auswählen

// Modulteil um Header zu inkludieren
module;
#include <stdlib.h>
#include <cmath>

// Hier nun unsere Submoduldefinition
export module BSMath.Base;

// Notwendige Importe
import BSMath.Vector2;
import BSMath.Vector3;
import BSMath.Vector4;

// Und direkte Implementierungen der Funktionen in unserem Namespace
namespace BSMath
{
	const float pi = 3.141592654f;

	export float degreeToRadian(float degree)
	{
	}

	export float radianToDegree(float radian)
	{
	}

	export unsigned int color(unsigned int r, unsigned int g, unsigned int b, unsigned int a)
	{
	}

	export unsigned int colorFromVector(Vector4& v)
	{
	}

	export void calculateTangentAndBitangent(Vector3& v0, Vector3& v1, Vector3& v2, Vector2& tu0, Vector2& tu1, Vector2& tu2, Vector3& tangent, Vector3& bitangent)
	{
	}

	export float randomNumber(float bottom, float top)
	{
	}
}
Ich hoffe das hilft dem ein oder anderen (Krishty? ;-) )vielleicht dabei den Einstieg in die Modulwert zu wuppen.
Ich fand es ehrlich gesagt nicht sehr intuitiv, aber nach einiger Zeit hat man es raus wann und wo das export, import und module Keyword hin muss.
Es gibt natürlich noch ne ganze Menge mehr zu wissen, aber dazu vielleicht ein anderes Mal mehr.

Fallstricke:
Wie bereits gesagt, ging mir der Umbau nicht gerade leicht von der Hand. Das mag zum einen an meiner recht langen C++ Abstinenz gelegen haben (beruflich bin ich mit PHP unterwegs und da bleibt leider wenig Zeit fürs Hobby), aber zum anderen sicherlich an der bisher doch recht dürftigen Unterstützung seitens VisualStudio.
Kompilierungsfehler werden scheinbar willkürlich geworfen. Man korrigiert Fehler A, kompiliert neu, dann taucht Fehler B auf, von dem vorher jede Spur fehlte. Nach dessen Korrektur taucht plötzlich Fehler C an einer Stelle auf, wo vorher noch alles bestens war und so geht das leider immer weiter. Ich hatte mehrfach das Gefühl, dass VisualStudio sich da selbst ziemlich verhaspelt und verschluckt und eigentlich noch gar nicht so wirklich richtig mit den Modulen klarkommt. Ein weiteres Graus ist leider Intellisense, das euch permanent überall irgendwelche Fehler anmäkelt, die aber tatsächlich nicht existieren. 5min später - ohne Änderungen gemacht zu haben - sind sie dann weg und es werden andere angezeigt. Mein PC ist übrigens hardwaretechnisch recht Highend und unausgelastet, daran kann es also eher nicht liegen.
Meine Tipps:
- Tastet euch langsam heran; Baut Klasse für Klasse um und kompiliert häufig neu
- Bereinigt das Projekt häufig, ggfs. vor jedem Kompilieren. Ansonsten schleppt ihr Altlasten mit und VS verschluckt sich garantiert
- Lasst euch von Intellisense nicht kirre machen; das letzte Wort hat schließlich der Compiler
- In meinem Fall (C++11 zu C++20) kamen noch einige neue Fehlermeldungen hinzu, die ich noch nicht kannte. Es mag Sinn machen, sich vor den Modulen vielleicht mal mit den Neuerungen aus C++17 und C++20 vertraut zu machen.

Ausblicke:
Als nächstes wird die 3D-Engine dann umgestellt. Mal schauen was da noch für Überraschungen auf mich warten. Aktuell bin ich aber sehr froh, dass alles wieder läuft und der neue Deferred Renderer das tut was er soll:
deferred.png
Benutzeravatar
Jonathan
Establishment
Beiträge: 1959
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: C++ Modules

Beitrag von Jonathan »

Hey,

vielen Dank für den Erfahrungsbericht, war interessant zu lesen und adäquat aufbereitet. Es freut mich zu hören, dass Module langsam praxistauglich werden aber es hört sich auch so an als sollte man vielleicht noch eine VisualStudio Version lang warten, bis man das produktiv benutzt, aktuell scheint das ja eher eine coole, aber nervige Spielerei zu sein.
Mal schauen. Ich fände Module natürlich primär interessant um die Compilierzeit zu reduzieren, andere Vorteile wie das aufräumen von Include-Chaos oder so nette Dinge wie min/max Definitionen in der windows.h habe ich aktuell eigentlich gut genug im Griff um dafür keinen Umstieg rechtfertigen zu können. Also wäre ich irgendwie darauf angewiesen, dass die externen Bibliotheken als Module vorhanden sind, bzw. ich müsste die selber entsprechend kapseln, oder?
Lieber dumm fragen, als dumm bleiben!
Specialist
Establishment
Beiträge: 124
Registriert: 29.08.2003, 14:22
Kontaktdaten:

Re: C++ Modules

Beitrag von Specialist »

Ja, so sehe ich das aktuell auch, es ist interessant es auszuprobieren, aber VS legt einem da noch zu viele Steine in den Weg um wirklich produktiv zu sein. Es wäre mal interessant zu wissen wie hier der Stand bei anderen IDEs ist, z.B. CLion.

VS unterstützt auch noch keine imports von Headern (import <cmath>), bietet aber wohl die Möglichkeit die Standardbibliothek als Modul einzubinden (muss extra installiert werden und erfordert nochmal ein Compilerflag mehr). Das wollte bei mir bisher aber noch nicht funktionieren - Modul std.core wird einfach nicht gefunden.

Bei Thirdparty-Code ist das auch noch so eine Sache. Da werden wir wohl noch eine Weile warten müssen, bis sich die Module dort durchgesetzt haben. Bis dato bleibt einem nichts anderes übrig oldschool die Header zu nutzen oder aber den Code selbst nochmal in Module zu kapseln (was generell ja nicht verkehrt sein sollte).

Übrigens bin ich bei Umstellung meines Netzwerkcodes nun tatsächlich an die Grenzen gestoßen. Ich inludiere <string> im Modul und das führt leider zu einem Bug in VS, für den es wohl auch keinen (offensichtlichen) Workaround gibt:
https://developercommunity.visualstudio ... -f/1339438
Also hier ist gerade bei mir erstmal Schluss mit Modulumstellung - leider.
Ich bleibe aber am Ball und werde berichten.
Benutzeravatar
Jonathan
Establishment
Beiträge: 1959
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: C++ Modules

Beitrag von Jonathan »

Specialist hat geschrieben: 06.04.2021, 11:40 Bei Thirdparty-Code ist das auch noch so eine Sache. Da werden wir wohl noch eine Weile warten müssen, bis sich die Module dort durchgesetzt haben. Bis dato bleibt einem nichts anderes übrig oldschool die Header zu nutzen oder aber den Code selbst nochmal in Module zu kapseln (was generell ja nicht verkehrt sein sollte).
Also, sollten sich Wrapper nicht ziemlich leicht automatisch generieren lassen?
Die meisten Bibliotheken haben ja einen oder ein paar zentrale Header die man includiert. Und man kann ja auch mit vorhandenen Werkzeugen recht leicht herausfinden, welche Symbole aus diesem Header man direkt benutzt. Man könnte also sein existierendes Spiel einmal parsen und damit (zumindest alle aktuell benutzten) öffentlichen Symbole extrahieren und müsste dann nur ein Modul schreiben, welches den Hauptheader inkludiert und alle öffentlichen Symbole nach außen exportiert. Solange die Bibliothek nicht auf irgendwelche Präprozessor-Schweinereien angewiesen ist, ist das doch ziemlich einfach, oder?
Und effizient sollte das doch auch sein. Man hat ja nichtmal Wrapper-Funktionen, die man später wegoptimieren muss, sondern macht einfach nur Symbole nach außen sichtbar. Und selbst wenn irgendwo durch diese Wrapper-Schicht Mehraufwand entsteht, sollte der doch durch den Nutzen mehr als aufgehoben werden.

Und insgesamt müsste man doch auch sehr gut Abwärtskompatibel sein können. Sprich zu jeder existierenden Lib braucht man dann bloß noch eine weitere Datei, die die gesamte Lib schön in ein Modul packt und man kann dann sowohl das eine, als auch das andere verwenden. Somit sollte man doch recht leicht Patches für existierende Bibliotheken schreiben können, die Modul-Support hinzufügen.
Lieber dumm fragen, als dumm bleiben!
Specialist
Establishment
Beiträge: 124
Registriert: 29.08.2003, 14:22
Kontaktdaten:

Re: C++ Modules

Beitrag von Specialist »

Man könnte also sein existierendes Spiel einmal parsen und damit (zumindest alle aktuell benutzten) öffentlichen Symbole extrahieren und müsste dann nur ein Modul schreiben, welches den Hauptheader inkludiert und alle öffentlichen Symbole nach außen exportiert. Solange die Bibliothek nicht auf irgendwelche Präprozessor-Schweinereien angewiesen ist, ist das doch ziemlich einfach, oder?
Ich denke das sollte an sich kein Problem sein, wenn es sich um einfache Bibliotheken handelt.
Je nachdem wie komplex die allerdings angelegt sind, bekommst du ggfs. Probleme mit Reachability etc., sprich es könnte schon aufwändig sein zu ermitteln was exportiert werden soll und vor allem wo genau es Sinn macht es zu exportieren. Aber ja, um erstmal grundlegenden Modulsupport zu leisten, könnte man einfach alles exportieren, was aber letztendlich nicht Sinn der Module ist.

Ich werde das mal mit lodepng (Eine Header + CPP) testen und schauen, wie aufwändig es in der Praxis wirklich ist.
Vielleicht komme ich da heute Abend sogar zu.
Specialist
Establishment
Beiträge: 124
Registriert: 29.08.2003, 14:22
Kontaktdaten:

Re: C++ Modules

Beitrag von Specialist »

Kurze Rückmeldung:
Sowohl lodepng als auch den DDSTextureLoader11 konnte ich problemlos jeweils in ein Modul verpacken.
Aber wie bereits gesagt sind das eher kleine Thirdparty-Module, die jeweils nur aus einer Header und CPP bestehen.
Bei größeren Libs wird es sicher mehr Aufwand sein.

Edit:
Ich weiß nicht, ob ich es gut oder schlecht finden soll, aber #pragma comment(lib, "xyz.lib") ist auch in der Modulschnittstelle möglich unter dem allgemeinen Modulteil (wo auch die includes stehen). Hat den Vorteil, dass das Modul direkt alle Abhängigkeiten mitbringen kann und man sich darum keine Gedanken mehr machen muss. Hat aber auch den Nachteil, dass Modul eben alle Abhängigkeiten mitbringt und man davon wenig mitbekommt, wenn es ein Fremdcode ist.
Specialist
Establishment
Beiträge: 124
Registriert: 29.08.2003, 14:22
Kontaktdaten:

Re: C++ Modules

Beitrag von Specialist »

Gute Nachrichten:
Nach Update auf Visual Studio 2019 16.10.0 scheinen die Module nun zu laufen.
Die STD-Module std.core, etc. werden nun auch ohne Probleme gefunden.
Es könnte sich also lohnen nochmal reinzuschauen. Meine ersten Tests sind auf jeden Fall gut gelaufen.

Nach ein paar kleinen Anpassungen läuft mein komplettes Projekt nun auf Modulen.
Einziges Problem scheint noch Intellisense zu sein, was zum Teil den Modulcode nicht finden kann
Das führt dann leider zu unzähligen False-Positives und einer nicht funktionierenden Autovervollständigung.
Ansonsten gibt es bisher keine Murren.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4514
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: C++ Modules

Beitrag von Schrompf »

Hast Du einen Unterschied in den Compile Times gemessen?
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Specialist
Establishment
Beiträge: 124
Registriert: 29.08.2003, 14:22
Kontaktdaten:

Re: C++ Modules

Beitrag von Specialist »

Leider nicht. Da ich vorher schon immer per Multiprocessor kompiliert habe, konnte ich nicht wirklich was feststellen.
Matthias Gubisch
Establishment
Beiträge: 380
Registriert: 01.03.2009, 19:09

Re: C++ Modules

Beitrag von Matthias Gubisch »

So ganz ausgereift sind die Module in Visual Studio noch nicht...

Die Umstellung ging eigentlich ganz gut von der Hand, bis ich beim einbinden des Headers einen externen lib über dieses Issue gefallen bin:
https://developercommunity.visualstudio ... rt/1230450
Upvotes natürlich gerne gesehen ;) auch wenn das Issue nicht von mir gemeldet wurde.

Soweit ich gekommen bin bisher konnte ich durchaus eine Verbesserung der Compilezeiten feststellen, wie viel allerdings von den Modulen kommt und wie viel davon dass ich die includes in dem Zuge grundsätzlich aufgeräumt habe kann ich leider nicht mehr feststellen.

Mein CoreLib besteht jetzt jedenfalls aus Modulen, und das Issue wird hoffentlich zeitnah gefixed so dass ich weiter umstellen kann ;)
Oder ich suche mir einen Ersatz für meine externe lib....

Nachtrag:
Ein Workaround der in dem fall zu funktionieren scheint:
anstatt

Code: Alles auswählen

import std.core;
die header units einzeln importeren, also:

Code: Alles auswählen

import <memory>;
import <thread>;
Dann scheint es zu tun
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
Benutzeravatar
Krishty
Establishment
Beiträge: 7850
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: C++ Modules

Beitrag von Krishty »

Mglw. von Interesse; ich werd’s bei meinem nächsten Anlauf durcharbeiten:

Visual C++ Team Blog: Using C++ Modules in MSVC from the Command Line Part 1: Primary Module Interfaces
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Specialist
Establishment
Beiträge: 124
Registriert: 29.08.2003, 14:22
Kontaktdaten:

Re: C++ Modules

Beitrag von Specialist »

Die Intellisense-Probleme mit Modules sind seit der neuen Version 16.11.1 verschwunden :)
Benutzeravatar
Krishty
Establishment
Beiträge: 7850
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: C++ Modules

Beitrag von Krishty »

Visual Studio 2022 unterstützt nun Modules mit CMake; allerdings nur, sofern man MSBuild als Backend einsetzt: https://devblogs.microsoft.com/cppblog/ ... e-with-vs/
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Matthias Gubisch
Establishment
Beiträge: 380
Registriert: 01.03.2009, 19:09

Re: C++ Modules

Beitrag von Matthias Gubisch »

Coole Sache
Muss ich die Tage gleich mal probieren
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
Matthias Gubisch
Establishment
Beiträge: 380
Registriert: 01.03.2009, 19:09

Re: C++ Modules

Beitrag von Matthias Gubisch »

Ich hab den CMake Support for C++-Modules von Visual Studio mal angetestet, vielleicht helfen meine Erkenntnisse ja jemanden ;)

1. Ninja als Generator tut so lange, bis man Abhängikeiten zwischen den Modulen einbaut.
Wenn ich 2 Module in eine CPP importiere läuft das auch mit Ninja als Generator, sobald man ein Modul in ein anderes importiert klappt das nicht mehr.
2. Clang steigt aus, sobald auch nur ein einziges Module definiert ist.
3. MSBuild + CMake scheint in meinem simplen Testcase ganz rund zu laufen, und auch Intellisense scheint stark verbessert in diesem Bereich.

Ich werde mal Testen ob ich meine Engine damit auf CMake umstellen kann und berichte gegebenfalls weiter.
Die Hoffung ist ja dass eines Tages Ninja + Clang in Visual Studio auch Module Support liefern
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
Benutzeravatar
Jonathan
Establishment
Beiträge: 1959
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: C++ Modules

Beitrag von Jonathan »

Hm, ja, ist interessant, aber sagt mir dann am Ende hauptsächlich, dass ich mit Modulen noch warten will...
Lieber dumm fragen, als dumm bleiben!
Benutzeravatar
Krishty
Establishment
Beiträge: 7850
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: C++ Modules

Beitrag von Krishty »

Microsoft berichtet, wie sie Office Stück für Stück auf Modules umstellen: https://devblogs.microsoft.com/cppblog/ ... -msvc-1-n/

Das dürfte für Leute interessant sein, die nicht ihre gesamte Codebase auf einmal umbauen wollen, sondern vielleicht mit den häufigsten Headern oder PCHs anfangen.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 7850
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: C++ Modules

Beitrag von Krishty »

Ich habe mich heute wieder etwas mit Modulen befasst, werde das aber weiterhin verschieben. Meine Begründung ist etwas eigen, aber naja: Ich habe Zweifel an der Performance.
Matthias Gubisch hat geschrieben: 20.03.2022, 14:521. Ninja als Generator tut so lange, bis man Abhängikeiten zwischen den Modulen einbaut.
Wenn ich 2 Module in eine CPP importiere läuft das auch mit Ninja als Generator, sobald man ein Modul in ein anderes importiert klappt das nicht mehr.
Mit Modules muss jedes Build-System jedes Modul zwei Mal kompilieren: Beim ersten Mal, um eine Abhängigkeitsliste der Module zu erzeugen; beim zweiten Mal (nachdem alle Abhängigkeiten gesättigt werden können) wird dann tatsächlich Code erzeugt. Das ist anders als bei Headern – die können zwar auch von anderen Headern abhängen, die müssen aber nicht erst kompiliert werden sondern liegen fertig rum. Deshalb kann eine CPP immer in einem Durchlauf kompiliert werden; Module erfordern zwei.

Normalerweise fällt das nicht ins Gewicht, sondern wird von dem stark verbesserten Durchsatz mehr als ausgeglichen. So ziemlich alle Projekte sehen eine Verbesserung der Kompilierzeit.

Das Ding ist … dass mein Zeug bereits schnell kompiliert, weil ich keine STL/CRT einsetze. Wie schnell? Pro C++-Datei im Schnitt fünf- bis zehnmal so schnell wie aufgeräumtes C++:
Bild
  • Die großen Brocken ganz links am Anfang sind der Quelltext von Ninja, in konservativem C++ mit STL/CRT.
  • Die wirklich großen Brocken sind Setups; darauf haben Modules keinen Einfluss.
  • Die mittleren Klötze sind das Linken von EXEs/DLLs mit Link-Time Code Generation. Ihr seht, dass das Linken und Optimieren eines kompletten Programms so lange dauert wie das Kompilieren von zwei C++-Quelldateien mit STL-#includes. (Fuck, das muss in den Anti-Jammer-Thread!)
  • Die ganzen kleinen Striche sind meine 1500 C++-Dateien mit Clang/MSCV – wobei der Clang-Build im Schnitt dreimal so lange pro Datei dauert wie MSVC, weil ich Address Sanitizer und Undefined Behavior Sanitizer eingeschaltet habe (die wirken sich extrem negativ auf die Kompilierzeit aus).
Wenn Matthias Gubisch nun schreibt
Matthias Gubisch hat geschrieben: 09.06.2021, 08:30Soweit ich gekommen bin bisher konnte ich durchaus eine Verbesserung der Compilezeiten feststellen, wie viel allerdings von den Modulen kommt und wie viel davon dass ich die includes in dem Zuge grundsätzlich aufgeräumt habe kann ich leider nicht mehr feststellen.
dann glaube ich sofort, dass Standard-C++-Quelldateien von Modules profitieren. Allerdings ist es offensichtlich, dass der #include-Overhead bei meinen eigenen Quelldateien 10× geringer ist, dass ich aber definitiv doppeltes Parsen zum Auflösen der Abhängigkeiten bezahlen muss.

Ich habe nun Schiss, dass ich unter extremem Aufwand auf Modules umstelle, und am Ende kompiliert alles langsamer als vorher.

Ich sollte am Wochenende ein paar Benchmarks schreiben und messen, statt das hier kaputtzuanalysieren …
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Matthias Gubisch
Establishment
Beiträge: 380
Registriert: 01.03.2009, 19:09

Re: C++ Modules

Beitrag von Matthias Gubisch »

So wirklich ausgereift sind Module zumindest unter Visual Studio auch noch nicht, von daher wuerde ich an deiner Stelle noch warten.
Ich hab das Modul-Projekt auch auf Eis gelegt aktuell.

Ein paar Punkte die mich gestört haben:
- Intellisense ist mit Modulen noch schlimmer als eh schon (das kann man teilweise mit VisualAssist abfangen, kost halt Geld)
- Seltsame fehler beim Linken(internal error), teilweise klappt linken erst aufs 2. oder 3. mal
- Solange mal ALLES in modulen verpackt hat kann man ganz gut arbeiten, aber wehe man packt externe libs hinzu die keine Module können (aktuell also fast alles) dann kommt man in die Hölle
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
Antworten