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

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.

    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
  • T

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

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

    Würd ich so nicht unterschreiben. Zumindest clangd, als LSP-Server, hängt doch direkt am clang Projekt.

    0
    F
     1 Antwort

  • @Schlangenmensch
    Mein Code:

    constexpr auto GetFoo() {
    std::array Table{
        1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
        11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
        21, 22, 23, 14, 15, 16, 17, 18, 19, 30,
        31, 32, 33, 34 };

    std::sort(std::begin(Table), std::end(Table));
    return Table;
}

static constexpr auto Foo = GetFoo();   // Fehler Intellisense : Der Ausdruck muss einen Konstantenwert aufweisen.

int main()
{
    return 0;
}
    0
  • F

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

    Würd ich so nicht unterschreiben. Zumindest clangd, als LSP-Server, hängt doch direkt am clang Projekt.

    Das dachte ich bei meinem letzten Test mit VSCode auch, dann kam aber das Clangd-Plugin nicht mit einer aktuellen Version klar - offenbar muss auch der Clangd-Client ein paar Dinge über Sprachfeatures wissen, auch wenn der Server die meiste Arbeit abnimmt. Und IntelliSense war ebenfalls nicht auf einem Stand, mit dem es die Konstrukte verstanden hat. Diese Info ist allerdings schon ziemlich alt - ich schrieb ja, dass das ne ganze Weile her ist bei mir. Ich denke mal das sieht aktuell deutlich besser aus.

    Wollte halt nur unterstreichen, dass das für mich eine Voraussetzung für produktiven Einsatz ist. Muss ich mir nochmal ansehen.

    0
Anmelden zum Antworten