3. Nutzt ihr eigene C++20 Module produktiv?

Nutzt ihr eigene C++20 Module produktiv?

  • L

    Ich glaube Modules haben es auch erst seit kurzem in CMake geschafft (ohne experimental flag etc.). Also würde vermuten mit neustem CMake, GCC 14 etc. sollte es vlt. jetzt langsam gehen, aber ist halt die Frage, ob man da wirklich der erste sein will, der sowas produktiv nutzt.

    0
    T
     1 Antwort
  • T

    @Leon0402 sagte in Nutzt ihr eigene C++20 Module produktiv?:

    Ich glaube Modules haben es auch erst seit kurzem in CMake geschafft (ohne experimental flag etc.). Also würde vermuten mit neustem CMake, GCC 14 etc. sollte es vlt. jetzt langsam gehen, aber ist halt die Frage, ob man da wirklich der erste sein will, der sowas produktiv nutzt.

    Wie sieht's denn gerade bei clang aus?

    0

  • In C++20 Modules Status Report gibt es eine Übersicht (wenn auch das letzte Update schon 10 Monate alt ist, aber die enthaltenen Links sind evtl. aktueller).

    0

  • Danke für die Antworten. Ich werde da wohl noch etwas warten, bis ich produktiv Module einsetzen werde.

    0
  • Mod

    Ich hatte schon fuer ein Hobbyprojekt vor circa 2 Jahren versucht, Modules zu integrieren (einfach aus Neugier/Jux), hat aber aufgrund mangelndem Support seitens des Compilers nicht funktioniert. Da hatte ich noch vermutet, das wuerde man 2023 ausmerzen.

    Riecht ein bisschen nach export template.

    0
  • *

    Kleines Update, da ich wegen dieses Postings es noch einmal mit dem GCC 14.1.0 probiert habe.

    Ich hatte vor zwei Jahren versucht ein Testprojekt (die Matrix Template Klasse, die ich hier mal gepostet habe) als Modul zu übersetzen. Das scheiterte schon beim Versuch ein Modul davon zu erzeugen sowohl mit GCC 11.x, 12.x und 13.x. Mit dem neuen GCC 14.1.0 lässt sich nun das Testprojekt übersetzen, und es liefert das gewünschte Ergebnis mit den Testprogrammen.

    Fazit zu GCC: Wer es probieren will, sollte unbedingt GCC 14.1.0 oder neuer einsetzen.

    0
    F
     1 Antwort
  • F

    @john-0 sagte in Nutzt ihr eigene C++20 Module produktiv?:

    Fazit zu GCC: Wer es probieren will, sollte unbedingt GCC 14.1.0 oder neuer einsetzen.

    Gut zu wissen. Meine Tests scheiterten damals aber auch vor allem an der Tool- und IDE-Integration. Am besten ging es damals noch mit Visual Studio und dem MSVC-Compiler. VSCode hatte hingegen selbst mit MSVC noch arge Probleme, von anderen Compilern gar nicht zu sprechen. In der Kommandozeile ließ sich das damals mit Clang durchaus bauen, aber wenn die IDE die Sprachkonstrukte (vor allem imports und die Funktionen/Klassen, die diese hereinziehen) nicht versteht und alles rot anstreicht, dann kann zumindest ich nicht wirklich "produktiv" damit arbeiten. clangd in VSCode (für "Sprachverständnis") scheiterte meiner Erinnerung nach an einer veralteten clangd-Version und Inkompatibilität des Plugins mit einer neueren. Ist vielleicht mal wieder Zeit das nochmal auszuprobieren - ich mache das in den letzten Jahren auch immer wieder mal.

    Meine Voraussetzung für (in privaten Projekten) "produktiv einsetzen" wäre jedenfalls neben Compiler-Support eine einigermaßen nahtlose CMake- und IDE-Integration für alle 3 der "großen" Compiler (MSVC, GCC und Clang), da ich zumindest bei eigenen Projekten Wert auf Portabilität lege.

    0
  • *

    So einen Bug scheint es im GCC 14.1.0 in Bezug auf Module zu geben.
    std::vector<T> funktioniert nicht, wenn man import <vector>; nutzt, und man muss std::vector<T,std::allocator<T>> verwenden, weil er sonst über einen fehlenden Template Parameter motzt.

    0
    F
     1 Antwort
  • F

    @john-0 sagte in Nutzt ihr eigene C++20 Module produktiv?:

    So einen Bug scheint es im GCC 14.1.0 in Bezug auf Module zu geben.
    std::vector<T> funktioniert nicht, wenn man import <vector>; nutzt, und man muss std::vector<T,std::allocator<T>> verwenden, weil er sonst über einen fehlenden Template Parameter motzt.

    Oh, btw... Sind die Module für die Standardbibliothek eigentlich schon standardisiert? import <vector> ist soweit ich weiß ein Header-Import für Bibliotheken, die nicht als Module vorliegen. In MSVC wäre das import std.core und meine letzte Info war, dass die Modul-Namen noch nicht wirklich einheitlich definiert wurden.

    Das wäre jedenfalls auch noch ein wichtiges Kriterium für mich: Keine #ifdef-Orgie mit Compiler/Feature-Detektion beim Einbinden der Standardbibliothek - und überhaupt auch erstmal selbige ebenfalls als Module.

    0
    *
     1 Antwort
  • *

    @Finnegan sagte in Nutzt ihr eigene C++20 Module produktiv?:

    Oh, btw... Sind die Module für die Standardbibliothek eigentlich schon standardisiert? import <vector> ist soweit ich weiß ein Header-Import für Bibliotheken, die nicht als Module vorliegen. In MSVC wäre das import std.core und meine letzte Info war, dass die Modul-Namen noch nicht wirklich einheitlich definiert wurden.

    Jetzt springst Du schon einen Schritt weiter nämlich von C++20 zum working draft von C++23. Verabschiedet ist die neue Norm noch nicht.

    In C++20 musst Du diesen Weg wählen, da es noch kein import std; bzw. import std.core; gibt. Die Norm schweigt sich dazu aus, was mit der Standard Library gemacht wird, daher wird es wohl eher so etwas wie ein Procompiled Header sein, den man da importiert.

    Stand C++20 mit GCC
    Man muss alle Module der Standard Bibliothek zuerst übersetzen (clang liefert sie fertig mit, unter Linux aber nur dann, wenn man die clang C++ Library nutzt und nicht die System C++ Library). Das erfolgt bisher mit

    g++-14 -std=c++20 -O3 -fmodules-ts -x c++-system-header -c complex

    für die Datei complex (analog für alle anderen Dateien der Norm). Das Modul wird dann im Arbeitsverzeichnis im Ordner gcm.cache unter dem Pfad der jeweiligen Standardbibliothek abgelegt. Da hier Compilermagie im Spiel ist, und man die Quelldatei nicht direkt angibt, ist es schwierig zu sagen was der Compiler da letztlich zu einem Binär-Modul verarbeitet. Wahrscheinlich ist der normale Header, aber das erklärt nicht den Fehler.

    Das wäre jedenfalls auch noch ein wichtiges Kriterium für mich: Keine #ifdef-Orgie mit Compiler/Feature-Detektion beim Einbinden der Standardbibliothek - und überhaupt auch erstmal selbige ebenfalls als Module.

    Bisher gibt es nur diesen Weg. Der Import von std.core ist ein Prerelease Feature des Compilers.

    0
    F
     1 Antwort
  • F

    @john-0 sagte in Nutzt ihr eigene C++20 Module produktiv?:

    @Finnegan sagte in Nutzt ihr eigene C++20 Module produktiv?:

    Oh, btw... Sind die Module für die Standardbibliothek eigentlich schon standardisiert? import <vector> ist soweit ich weiß ein Header-Import für Bibliotheken, die nicht als Module vorliegen. In MSVC wäre das import std.core und meine letzte Info war, dass die Modul-Namen noch nicht wirklich einheitlich definiert wurden.

    Jetzt springst Du schon einen Schritt weiter nämlich von C++20 zum working draft von C++23. Verabschiedet ist die neue Norm noch nicht.

    Oh, das hatte ich gar nicht auf dem Schirm. In dem Fall definitiv erst "produktiv" wenn import std mit den drei großen Compilern "out of the box" möglich ist. Gerade wenn nur die Standardbibliothek verwendet wird finde ich, dass der Code unmodifiziert (auch ohne #ifdefs) mit allen unterstützenden Compilern laufen sollte. Die std wird ja nahezu überall eingebunden, da hätt ich nur ungern eine Notlösung in jeder Datei des Projekts. Auch wenn das gemessen am gesamten Modules-Support wahrscheinlich nur ein relativ "unbedeutendes Detail" ist.

    "Experimentell" werd ich natürlich weiterhin reinschauen und damit herumspielen 😁

    0
    S
     2 Antworten

  • @Finnegan sagte in Nutzt ihr eigene C++20 Module produktiv?:

    "Experimentell" werd ich natürlich weiterhin reinschauen und damit herumspielen

    Ich habe vor kurzem auch mal eine constexpr Funktion geschrieben, welche ein sortiertes Array zurück gibt. Hierbei zeigten sich ein paar IntelliSense Probleme.

    Ist das Array mehr als 32 Elemente groß, so schlägt IntelliSense mit der Meldung "Der Ausdruck muss einen Konstantenwert aufweisen" an. Auch bei der Sortierfunktion < (Klassenoperator vs. globale Funktion) zeigten sich diverse IntelliSense Probleme.

    Da ist also noch einiges buggy.

    0
    F
     1 Antwort
  • S

    @Finnegan Ich habe vor 2 Monaten oder so mal mit msvc import std; versucht. Das war da noch murks Wenn an anderer Stelle im Projekt noch altmodische std includes verwendet wurden, gab's Fehler wegen wegen redefinition von Symbolen.

    Seitdem habe ich das nicht mehr probiert, um ehrlich zu sein. 😉

    0
    F
    *
     2 Antworten
  • F

    @Quiche-Lorraine sagte in Nutzt ihr eigene C++20 Module produktiv?:

    Ich habe vor kurzem auch mal eine constexpr Funktion geschrieben, welche ein sortiertes Array zurück gibt. Hierbei zeigten sich ein paar IntelliSense Probleme.

    Das schreckt mich am meisten ab, auch wenn das nur wenig mit dem Compiler-Support zu tun hat. Bei meinen Modules-Experimenten vor längerer Zeit war der Quellcode zwar korrekt, aber dennoch fast komplett rot angestrichen. Kann man zwar ausschalten, aber dieses Feature ist ja eigentlich auch ziemlich hilfreich. Abgesehen davon, dass dann auch Dinge wie ""Gehe zu Deklaration/Definition" und Refaktorisierung nicht ordentlich funktionieren. Das ist mir für produktive Arbeit auch extrem wichtig.

    0
    T
     1 Antwort
  • F

    @Schlangenmensch sagte in Nutzt ihr eigene C++20 Module produktiv?:

    @Finnegan Ich habe vor 2 Monaten oder so mal mit msvc import std; versucht.

    import std.core; lief da bei mir immer recht gut. Ist aber wohl MSVC-spezifisch. Es sollte eigentlich import std; bzw. import std.compat; heißen (ab C++23), letzteres wenn man auch noch die C-Deklarationen der Standardfunktionen im globalen Namespace haben will (fopen/fclose und sowas).

    0
    S
     1 Antwort
  • S

    @Finnegan hm, ich hatte u.a. auch mit dem Spaceship Operator experimentiert. Mein minimales Beispiel war sowas:

    test.ixx:

    export module test;
import <compare>;

export struct Test
{
  double value{};
  auto operator<=>(const Test&) const = default;
};

    und in meiner playground.cpp

    #include <iostream>
import test;

int main()
{
  Test test;
  test.value = 2;
  std::cout << test.value;
  return 0;
}

    So geht das. Wenn ich anstatt import <compare>; import std; nutze, bekomme ich error C1117: unrecoverable error importing module 'std': symbol 'partial_ordering' has already been defined,

    std.core scheint VS gar nicht zu kennen. Kann es sein, dass man das extra installieren muss?

    Ich kann auch in der cpp #include <iostream> durch import std; ersetzen, dann funktioniert das auch. Aber, in größeren Projekten ist es doch eher schwer alles auf einmal zu ändern.

    0
    F
     2 Antworten
  • F

    @Schlangenmensch sagte in Nutzt ihr eigene C++20 Module produktiv?:

    std.core scheint VS gar nicht zu kennen. Kann es sein, dass man das extra installieren muss?

    Soweit ich mich erinnere benötigte ich für import std.core; die Compiler-Flags -std:c++latest -experimental:module und die Modul-Version der Standardbibliothek war als separates Paket im VS Installer anwählbar. Ist aber schon ne Weile her, da dürfte sich sicher etwas geändert haben.

    In diesem Tutorial hier ist sogar davon die Rede, dass die Standardbibliothek eigens via Kommandozeile als Modul kompiliert werden muss (für import std;/import std.compat;). Vielleicht hilft das ja weiter.

    Scheint noch was zu dauern mit dem "out of the box" 😁

    0
  • *

    @Schlangenmensch sagte in Nutzt ihr eigene C++20 Module produktiv?:

    @Finnegan Ich habe vor 2 Monaten oder so mal mit msvc import std; versucht. Das war da noch murks Wenn an anderer Stelle im Projekt noch altmodische std includes verwendet wurden, gab's Fehler wegen wegen redefinition von Symbolen.

    Das könnte ganz banal daran gelegen haben, dass die Includes zuspät erfolgte. Man muss eine bestimmte Reihenfolge einhalten, die Includes müssen sehr früh erfolgen, und danach dürfen nur noch imports erfolgen, sonst werden die Symbole aus den Includes rexportiert.

    0
    F
     1 Antwort
  • F

    @john-0 sagte in Nutzt ihr eigene C++20 Module produktiv?:

    Das könnte ganz banal daran gelegen haben, dass die Includes zuspät erfolgte. Man muss eine bestimmte Reihenfolge einhalten, die Includes müssen sehr früh erfolgen, und danach dürfen nur noch imports erfolgen, sonst werden die Symbole aus den Includes rexportiert.

    Stimmt, da war was. Das müsste ich mein Wissen aber auch nochmal genauer auffrischen. Soweit ich mich erinnere müssen zumindest klassische Präprozessor-Includes in das global module fragment (zwischen einem module; und dem export module ...):

    module;

#include <iostream>

export module test;
...

    Sonst werden die Symbole aus dem Header ebenfalls mit exportiert. Und für importierbare Header mit import gelten auch soweit ich weiß spezielle Regeln, da der Zustand des Präprozessors vor dem import keinen Einfluss auf den Header hat. Wenn da irgendwelche #defines nötig sind, damit der Header richtig funktioniert, dann wird das möglicherweise nicht funktionieren (oder nur für solche #defines die via -D in der Compiler-Kommandozeile mitgegeben wurden). Da Module "kompiliert" werden, gehe ich auch davon aus, dass diese #defines dann wahrscheinlich fest ins Modul "eingebacken" werden.

    Aber mir scheint, dass das jetzt nicht das Problem von @Schlangenmensch war, da das #include nicht im Modul-Code selbst stattfand. Dennoch erwähnenswert.

    Das import std; anstatt import <compare>; sollte meinem Verständnis nach eigentlich in Ordnung sein.

    0
  • *

    Zu früh gefreut, ich dachte ich hatte das Modul für die Testprogramme genutzt, es war noch der Header. Nach der Umstellung funktioniert es zwar trotzdem und es gibt bei der Ausführung keine wirklichen Probleme, aber ein hässlicher Fehler tritt auf. Der Compiler gibt folgende Warnung aus:

    matrix.cc:308:69: Warnung: unverwendeter Parameter »j« [-Wunused-parameter]
  308 |                 const IndexType i [[maybe_unused]], const IndexType j [[maybe_unused]]) noexcept

    Tja, warum habe ich da wohl [[maybe_unused]] zum Parameter geschrieben?!

    0
Anmelden zum Antworten