Ich hab mir in den letzten Wochen die Vorträge von der letzten C++ Konferenz angeguckt und auch ein Vortrag über die kommenden Modules gesehen.

Da Microsoft und Google das sehr massive pushen, gibt es schon eine Implementierung für VS2017, clang und gcc(noch sehr frische implementierung).
Ich hab mal CMake so angepasst, dass ich mit VS2017 das ganze ausstesten kann und hab mein Radon Framework und das neue Radon Framework Enterprise zum testen genommen.

Ich hab eine minimale Testapp geschrieben(ein BDD-Test) und nutze RF und RFE in diesem. Das ganze hab ich vollständig mehrmals gebaut und dann die Zeiten notiert.
Nun fasse ich gerade mehrere Bereiche im RF, wie z.B. Core in einem Modul zusammen und nehme statt der Header nun das Modul im restlichen code und vergleiche dann wieder.
Das wird wohl erst am Wochenende so weit sein, von daher kann ich noch nix zur praxis sagen.
In der Theorie ist es wesentlich schneller und sicherer.

Modules können:
* keine Macros veröffentlichen -> Preprozessor hat nur noch die Globalen und Unit-Lokalen Defines zu verarbeiten
* declaration und definition enthalten, ohne kollision
* typen müssen explizit exportiert werden um verfügbar zu werden -> pimpl pattern wird nicht mehr gebraucht
* include und export der Funktionen, Typen, Klassen, Variablen in extra modules(ein Standard System für alle Compiler) -> precompiled header sind nicht mehr nötig
* einfacher ausgelesen werden, da sie dem IFC Standard folgen, den der Erfinder von C++ designed hat und von MS auch schon viele Jahre verwendet wird
* reduzierung den Compiler und Linker Aufwand durch reduzierung gleich am Anfang -> header sind nur noch notwendig, wenn man shared libs baut wobei auch das sich ändern wird
* eine bessere paketierung bieten

Das Thema ist echt toll und ich hoffe da bald erste Ergebnisse liefern zu können.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Muss mir mal die Videos anschauen. Bin ich bisher noch nicht dazu gekommen.
Berichte gerne wie es geklappt hat.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Die test app hab ich nun über modules gebaut.
Die App selber braucht erstaunlich wenig Code am Ende.
Ich musste diverse Header anpassen, weil ich mit precompiled header und einem monolythischen Header arbeite.
Ich hab also für alle Typen, Klassen und so weiter nun die nötigen Module gebaut und die Typen exportiert. Die App brauch rund 2 Sekunden zum bauen und linken. Mein framework selber rund 12 Sekunden. Nach dem Umbau auf modules braucht die app noch 1,5 Sekunden und verbringt die meiste Zeit im linker.

In anbetracht, dass ich die compile time stark reduziert hab, weil es garkeine includes mehr gibt hat sich da wie versprochen viel getan.

Die Entwicklung von cpp und hpp oder einer mpp file sind eher nicht messbar und ich tendiere zu mpp und cpp, weil bei komplexeren units es schnell unübersichtlich wird.
Der größte Nachteil bei closed source ist, dass man kein code mehr zum rein gucken hätte. Mpp wird zu einer ifc file compiliert und die ist nur noch mit tools lesbar. Eine Header file oder die mpp selber kann man noch mit jedem Editor lesen.

Für open source ist es toll. Eine mpp file pro unit und dann sammel module um nicht jedes Modul importieren zu müssen.

Ein weitere Punkt, der mir aufgefallen ist, ist die Notwendigkeit von Headern. Da ein Modul keine defines weiter gibt aber man einige defines immer wieder hat, wie z.B. Compiler version, Hardware features und abhängig von Z.B. endian Support unterschiedliche Implementierungen und Deklarationen nutzt, wird es kniffeliger. Entweder verwendet man weiterhin includes dafür, global defines oder baut compile time Konstruktionen mit generierten files.
Also so einfach ist die Portierung dann doch nicht.

Ich grübel noch, wie ich weiter portieren werde. Damit auch mein framework von den performance boost profitiert, muss ich die includes über preprocessor zwischen Modul Import und include wechseln lassen. Dass große Problem mit dem precompiled header muss ich auch lösen, dass dieser beim Modul Export deaktiviert wird.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich bin nun wieder ein ganzen Schritt weiter gekommen und ich hab was gefunden, wo kein Modul der Welt helfen kann

Folgendes Makro ersetzt den ursprünglichen Aufruf durch ein bisschen Code aber wichtiger, es konvertiert den test Ausdruck zu einem String und fügt die File und Line Defines mit an der Codestelle ein. Dies ist nötig, damit im nächsten Durchlauf dann diese aufgelöst werden können und de wirkliche Datei und Zeile im Code haben. Dies würde mit Metaprogramming nicht gehen, da die Defines sich nicht im Kompilierprozess bewegen und damit würde er beim Metaprogramming immer die Assert.hpp angeben und die Zeile dort drin.


Es gibt noch ne menge zu tun, es ist echt schön zu sehen, wie einige kleine Designfehler hoch poppen.
Ich hab sehr viele defines benutzt, weil früher kein constexpr gab und entsprechend der code drin blieb, weil man könnte ja zur Laufzeit durch laufen.
Defines und Preprocessor haben hier Code an- und abschalten können.
Nun mit if-constexpr und constexpr function geht es aber sehr wohl.



Gleiches gilt auch für OS Code. Am Anfang hatte ich die Systemfunktionen per Defines in einer Code Unit an- und abgeschalten und später hab ich die Funktionen für jedes OS in eine seperate Datei gepackt und vom Build ausgeschlossen. Nun der Alte Code fällt mir nun auf die Füße, weil er von nicht mehr gewollten RF_WINDOWS, RF_OSX, RF_UNIX,... Makros geplagt ist und um die Defines los zu werden muss erstmal der alte Code auf den neuen Stiel refactored werden, damit man danach dann die Defines weg bekommt. Es macht auch Sinn, das OS nochmal als constexpr an zu legen, da man so toten Code aus dem Programm bekommt.

Bei den Instruction-Sets hab ich auch Defines ins Framework geben. Es macht aber mehr sinn die optimierten Funktionen in seperate Units zu verschieben und vom Build aus zu schliessen, was der Compiler nicht kann. Zusätzlich macht es aber Sinn noch constexpr zur verfügung zu stellen, damit man besseres function dispatching machen kann.


BuildInfo::HostOS ist ein constexpr und damit kann zur Kompilierzeit ganz genau entschieden werden, welcher Code zur Laufzeit erreichbar ist und entsprechend den rest aus dem Build nehmen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Auf die Idee #defines durch constexpr zu ersetzen bin ich noch nicht gekommen. Werde ich mal anwenden.

Das Problem mit __FILE__ und __LINE__ ist, dass es Compilerdefines sind und kein Sprachkonstrukt.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Ich hab von Stroustrup und 2 anderen eine Publikation für das ersetzen von Macro und Defines gefunden.
http://www.stroustrup.com/icsm-2012-demacro.pdf

Ich bin fast durch mit dem anpassen der includes und dann kann ich die Modules weiter bauen und sehen wieviel es dann beim kompilieren insgesammt bringt

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Bzgl __FILE__, __LINE__ und __FUNCTION__ gibt es Hoffnung: https://en.cppreference.com/w/cpp/exper ... e_location

Ich weiß nicht, in wie weit das schon von den compilern unterstützt wird aber ich bin gerade über entsprechende GCC builtins gestolpert, die das schon implementieren sollten.
Siehe https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html "__builtin_LINE" und folgende.

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Das ist super und ich will das haben aber vc++ hat die nötigen intrinsic noch nicht implementiert

Ich hab leider aktuell ein internen Compiler error und kann nicht durch kompilieren. Aktuell fixe ich mit clang-Format ung clang-tidy diverse Kleinigkeiten und baue dann weitere Module. Vc++ hat vor kurzem bessere Module Fehler Codes eingebaut aber bei internen Compiler Fehler ist Stille, lediglich die Info, dass ich den Code reduzieren soll, um den Fehler ein zu kreisen.

Man muss bei cmake per Hand die Abhängigkeit behandeln.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Shaijan war schneller. Hatte es heute auch gefunden:
https://foonathan.net/blog/2017/05/08/preprocessor.html

Habe es auch versucht bei mir umzusetzen, aber die meisten sind Conditionale #defines und #ifdefs und da klappt es leider nicht, da dadurch auch Memberfunktionen bzw. Variablen hinzugefügt werden.
Ihr habt da auch keine Lösung für sowas?

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Ich hab nun noch weiter an den erstellen von Modules gearbeitet aber der VSC++ Compiler hängt sich hier und da an Sprachkonstrukte auf und bringt interne Compiler Fehler.
Ich warte nun auf die nächste Version, was wohl VS2019 Beta ist.

Was es sehr aufwändig macht sind Abhängigkeiten unter den Modulen. Man muss ja jedes Modul in richtiger reihenfolge kompilieren und wenn man jede Klasse in ein eigenes Modul packt, dann muss man dann jede einzelne Datei per Hand pflegen.

Dieser umstand ist echt ein Problem, da man den Code parsen müsste, dann die Abhängigkeiten einpflegen müsste, um die Hürde niedrig zu halten, denn ich hab z.B. 260 Source Files im Radon Framework und das wäre ne sehr lange CMake file.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004