Nutzt ihr eigene C++20 Module produktiv?

Finnegan

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

Finnegan

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

Schlangenmensch

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

Finnegan

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

*john 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.

Finnegan

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

*john 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?!

Tyrdal

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

Quiche Lorraine

@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;
}

Finnegan

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