<filesystem> gcc 8.1.0



  • Ja



  • Danke



  • This post is deleted!


  • Wenn das ok ist, können wir hier dann mit boost/filesystem weitermachen? Komme damit nämlich auch nicht klar. Habe das aktuellste nuwen mingw ( 16.0 ) auf C:\ entpackt. Die IDE ist CodeBlocks.

    Unter Link Libraries habe ich C:\MinGW\lib\libboost_filesystem.a
    unter Search directories C:\MinGW\include\boost\filesystem
    eingetragen.

    Wird aber beim includen nicht gefunden. Wie muss ich vorgehen?



  • @lemon03 Evtl reicht ein Austausch der \ durch / bei den Angaben der Directories



  • Der Suchpfad sollte C:\MinGW\include heissen. Dann kannst du mit boost/filesystem.hpp ansprechen.



  • Danke. Ich musste unter 'other linker options'

    -lboost_system
    -lboost_filesystem
    

    eintragen. Unter 'Link Libraries' gar nichts und unter 'Search directories' das obige

    C:\MinGW\include
    

    Dann gibt es aber zwei Warnungen
    C:\MinGW\include\boost\mpl\assert.hpp|188|warning: unnecessary parentheses in declaration of 'assert_arg' [-Wparentheses]|
    C:\MinGW\include\boost\mpl\assert.hpp|193|warning: unnecessary parentheses in declaration of 'assert_not_arg' [-Wparentheses]|
    die man ignorieren soll? Finde ich nicht so gut. Und ich schätze, sobald ich etwas anderes von boost benutzen will, geht das Spiel wieder von vorne los?

    Dann würde ich gerne noch Visual Studio versuchen, um mich endgültig zu entscheiden. Dort gibt es ähnliche Probleme mit <filestream>
    Error E1696 cannot open source file "filestream"
    Error C1083 Cannot open include file: 'filestream': No such file or directory

    Zwar kann man die Fehlercodes anklicken, die Treffer haben aber wenig mit filestream zu tun, mehr mit eigenen Headern. Wie gehe ich hier vor?



  • Welche version von Visual Studio verwendest du?

    Und mann muss auch einstellen welchen c++ standard verwendet werden soll:

    https://stackoverflow.com/questions/50668814/vs2017-e0135-namespace-std-has-no-member-filesystem



  • This post is deleted!


  • This post is deleted!


  • @lemon03

    Dann folgt aber gleich die beliebte Anfängerfrage, wie halte ich die Konsole offen? Ohne extra Warteschleife im Code? Es ist zum verrückt werden!

    Wenn man ein Programm aus VS startet, macht zumindest 17.9 das bei mir automatisch.



  • @lemon03 sagte in <filesystem> gcc 8.1.0:

    Dann folgt aber gleich die beliebte Anfängerfrage, wie halte ich die Konsole offen? Ohne extra Warteschleife im Code? Es ist zum verrückt werden!

    Ach du willst uns doch bloß verarschen.



  • This post is deleted!


  • Du solltest auch keine Hilfe mehr benötigen. Nach all diesen Jahren noch so eine Frage stellen zu müssen, da will ich dir gar von programmieren abraten.



  • This post is deleted!


  • Sehe ich auch so.

    Für mich verschwendest du deine Zeit damit. Als Programmierer musst du auch irgendwann einmal selber deine Fehler nachvollziehen und beheben können.

    Nimms mir nicht übel.



  • Weil ich mich gerade etwas ärgere habe ich den Start mal aufgenommen.

    https://youtu.be/NqgJ3JQbE9s

    Wenn mir jetzt jemand sagt, was ich dort falsch gemacht habe, werde ich in Demut eine Weile in mich gehen.



  • @lemon03 sagte in <filesystem> gcc 8.1.0:

    Weil ich mich gerade etwas ärgere habe ich den Start mal aufgenommen.

    https://youtu.be/NqgJ3JQbE9s

    Wenn mir jetzt jemand sagt, was ich dort falsch gemacht habe, werde ich in Demut eine Weile in mich gehen.

    Du hast im Menü "Start Debugging" (F5) ausgewählt. In diesem Fall wird die Konsole nicht automatisch offen gehalten. Im Debug-Modus kannst du einen Breakpoint ans Programmende setzen wenn du die Konsole offen halten willst.

    Wenn du stattdessen "Start without Debugging" (Ctrl+F5) wählst, wartet er automatisch auf einen Tastendruck nach Programmende.

    Ctrl+F5 startet das Programm auch ein klein wenig flotter und ist bei mir zumindest der Standard, wenn ich das, was ich gerade eben programmiert habe testen will.

    Ich finde es auch etwas ungünstig, dass der grosse, einladende "Play-Button" für den Debugger steht, der die Konsole direkt zumacht. Man kann da schnell den Eindruck bekommen, dass VS nichts anderes kennt. Daher sieht man wohl auch so oft die system("PAUSE")-Krücke in Anfängercode 😉



  • @Finnegan

    Du hast im Menü "Start Debugging" (F5) ausgewählt. In diesem Fall wird die Konsole nicht automatisch offen gehalten. Im Debug-Modus kannst du einen Breakpoint ans Programmende setzen wenn du die Konsole offen halten willst.

    Das stimmt so nicht mehr. In VS 2017 wird auch im Debugger die Konsole nicht geschlossen. Das kann in den Einstellungen auch anders konfiguriert werden. Allerdings war das Verhalten nach dem Einspielen von Patches auch mal anders. Seit 17.9 ist es bei mir bisher immer aktiv.



  • @spiri sagte in <filesystem> gcc 8.1.0:

    Hast du stdc++fs verlinkt?

    Versuchs mal mit dem Experimental-Header (#include <experimental/filesystem>)

    Ich habe des starken Verdacht, dass die <filesystem>-Unterstützung der libstdc++ unter Windows immer noch unvollständig ist. Ich verwende einen selbst kompilierten GCC 8.2.0 mit Backport-Patches für <filesystem> sowie einen ein paar Tage alten GCC 9 aus dem Entwicklungs-Branch, welche auf der C-Standardbibliothek von MinGW aufbauen. Beide haben zwar beim Kompilieren eine libstdc++fs.a erzeugt und laufen bei einem #include <filesystem> auch nicht auf irgendwelche Fehler, allerdings beschwert sich der Linker, dass anscheinend einige Implementationen diverser Funktionen fehlen (mit -lstdc++fs (!)):

    #include <iostream>
    #include <filesystem>
    
    namespace fs = std::filesystem;
    
    auto main() -> int
    {
        for (auto& entry : fs::directory_iterator("C:\\"))
            std::cout << entry.path() << std::endl;
        return 0;
    }
    
    undefined reference to `std::filesystem::__cxx11::directory_iterator::operator*() const'
    undefined reference to `std::filesystem::__cxx11::directory_iterator::operator++()'
    undefined reference to `std::filesystem::__cxx11::filesystem_error::_M_gen_what()'
    undefined reference to `std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path const&, std::filesystem::directory_options, std::error_code*)'
    undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
    undefined reference to `std::filesystem::__cxx11::filesystem_error::~filesystem_error()'
    undefined reference to `vtable for std::filesystem::__cxx11::filesystem_error'
    

    Schade. Das sieht so aus als bräuchte die libstdc++ noch etwas Arbeit. Möglicherweise sind auch nur ein paar #defines nicht ganz so wie sie sein sollen. Soweit ich das beurteilen kann ist das kein MinGW-Problem (nur eine C-Standardbibliothek und Import-Bibliotheken für die Windows-API), sondern eine fehlende Unterstützung seitens der libstdc++.

    Es scheint als müsse man sich mit MinGW-basierten Compilern noch weiter gedulden oder eben boost::filesystem verwenden. Zum Trost kann man dann stattdessen mit dem MinGW-GCC schon mit Concepts arbeiten 😉


Log in to reply