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

Nutzt ihr eigene C++20 Module produktiv?

  • 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