<filesystem> gcc 8.1.0



  • @manni66 sagte in <filesystem> gcc 8.1.0:

    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.

    Oha, da bin ich tatsächlich nicht mehr auf dem neuesten Stand - zuviel unter Linux gearbeitet in letzter Zeit. Ja, ich habe das gerade nochmal mit VS2017 ausprobiert und bei einer neu erstellten "Console Application" wartet er beim Ausführen wie auch beim Debuggen auf eine Eingabe. Danke für den Hinweis 😉



  • @Finnegan sagte in <filesystem> gcc 8.1.0:

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

    Ich habe sowohl 'start debugging' als auch 'start without debugging' gewählt, wie im Video zu sehen.

    @Finnegan sagte in <filesystem> gcc 8.1.0:

    Ja, ich habe das gerade nochmal mit VS2017 ausprobiert und bei einer neu erstellten "Console Application" wartet er beim Ausführen wie auch beim Debuggen auf eine Eingabe. Danke für den Hinweis 😉

    Ja, das tut er. Nur kennt er dann wieder kein <filestream>. Sorry, <filesystem>



  • @lemon03 sagte in <filesystem> gcc 8.1.0:

    @Finnegan sagte in <filesystem> gcc 8.1.0:

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

    Ich habe sowohl 'start debugging' als auch 'start without debugging' gewählt, wie im Video zu sehen.

    Jo, Sorry! Da hab ich tatsächlich zu oberflächlich geschaut, sah auf den ersten Blick so naheliegend aus 😉 ...

    @Finnegan sagte in <filesystem> gcc 8.1.0:

    Ja, ich habe das gerade nochmal mit VS2017 ausprobiert und bei einer neu erstellten "Console Application" wartet er beim Ausführen wie auch beim Debuggen auf eine Eingabe. Danke für den Hinweis 😉

    Ja, das tut er. Nur kennt er dann wieder kein <filestream>.

    ... allerdings sind hier auch ein paar gelöschte Beiträge, so dass ich jetzt nicht nachvollziehen kann, was du geändert hast, so dass er nicht mehr auf eine Eingabe wartet (?). Meinst du mit <filestream> hier jetzt <filesystem> oder etwas anderes?

    Mit einem simplen <filesystem>-Test habe ich unter VS2017 jedenfalls keine Probleme, und auf eine Eingabe nach dem Ausführen/Debuggen wartet er auch:

    #include "pch.h"
    #include <iostream>
    #include <filesystem>
    
    // Siehe: https://docs.microsoft.com/en-us/cpp/standard-library/filesystem?view=vs-2017
    // "As of the release of Visual Studio 2017, the <filesystem> header was not yet a C++ 
    // standard. Visual C++ 2017 implements the final draft standard, found in ISO/IEC 
    // JTC 1/SC 22/WG 21 N4100."
    namespace fs = std::experimental::filesystem::v1; 
    
    auto main() -> int
    {
    	for (auto& entry : fs::directory_iterator("C:\\"))
    		std::cout << entry.path() << std::endl;
    	return 0;
    }
    

    Ausgabe:

    C:\$Recycle.Bin
    C:\Config.Msi
    C:\Documents and Settings
    C:\hiberfil.sys
    C:\pagefile.sys
    C:\swapfile.sys
    C:\Users
    C:\Windows
    ...
    

    Ist jetzt natürlich ein doofes "Works for me". Was hast du denn konkret anders gemacht? Meins ist einfach nur ein neues Konsolen-Projekt mit obigem Code (nichts am Projekt verändert, nur den Default-Code mit dem Code oben ausgetauscht).

    Finnegan



  • Erstens sorry wegen den gelöschten Beträgen, war etwas angefressen und hatte gar nicht mehr damit gerechnet, das das noch jemanden interessiert. Zweitens sorry, das ich jetzt nicht zitiere, Dein Beitrag ist mir im Moment zu groß.

    Was gewesen ist: Hatte in Visual Studio als erstes eine Windows Console Application erstellt, schien mir für mein Projekt naheliegend. Die Konsole blieb ähnlich wie bei CodeBlocks offen. War für mich selbstverständlich. Kannte ja nichts anderes. Dort wurde aber kein <filesystem> erkannt. Also nachgefragt, nachdem es in gcc nicht geht, über boost nur mit eigenartigen Warnungen, und nun auch in Visual Studio nicht.

    Dann festgestellt, das man ein leeres Projekt erstellen muss, damit <filesystem> bekannt ist, nur gab es das "beliebte Anfängerproblem", das die Konsole nicht offen blieb. In der Hoffnung, das man die Ironie dieser Umschreibung erkennt und mir einfach verrät, warum die Konsole nicht offen bleibt, habe ich ganz naiv danach gefragt.

    Und dann nahm das Übel seinen Anfang...

    Wenn bei Dir auch in einer Console Application <filestream> bekannt ist, muss es an den vorkompilierten Headern liegen, die ich als erstes abgeschaltet habe.



  • @lemon03 sagte in <filesystem> gcc 8.1.0:

    Wenn bei Dir auch in einer Console Application <filestream> bekannt ist, muss es an den vorkompilierten Headern liegen, die ich als erstes abgeschaltet habe.

    Nein, auch mit ausgeschalteten PCH und ohne #include "pch.h" läuft das obige Beispiel bei mir genau so wie beschrieben.

    Bezüglich <filestream>: Bist du sicher, dass du nicht <fstream> meinst? Möglich, dass da was an mir vorbei gegangen ist, aber soweit ich weiss gibt es keinen <filestream>-Header.

    Bezüglich des Namespace std::experimental::filesystem::v1: Ohne Änderung am neu erstellten Projekt muss ich diesen experimental-Namespace verwenden. Wenn ich den Sprachstandard unter Project->Properties->C/C++->Language->C++ Language Standard auf /std:c++17 oder /std:c++latest stelle, dann funktioniert es auch mit std::filesystem.

    Getestet mit Microsoft Visual Studio Community 2017, Version 15.8.7 und cl.exe Version 19.15.26730 for x64.



  • Verdammt, eigentlich ist <filestream> ein Schreibfehler von mir, den ich hier schon öfters gemacht habe wie mir scheint. Es soll sich natürlich immer um <filesystem> handeln. Diesen Schreibfehler habe ich wohl auch in Visual Studio gemacht. Keine Ahnung, wie dies geschehen ist.

    Jedenfalls habe ich mir dort das "fehlgeschlagene" Projekt angeschaut, in welchen ich <filesystem> verwenden wollte und dort stand tatsächlich <filestream>.

    Tja, ist etwas peinlich. In einem meiner gelöschten Beiträge habe ich geschrieben ... dann werde ich in Demut eine Weile in mich gehen... Das werde ich nun mal machen.

    Nochmal zusammengefasst:
    In einer Windows Console Application ohne precompiled header ist <filesystem> bekannt und es bleibt die Konsole offen.
    Punkt.

    Danke für das Zurückschieben in die richtige Spur.



  • Ich hatte mit GCC 8.1.0 und <filesystem> auch mal Probleme ... Ich glaube unter Windows zumindest ist/war das broken. Würde GCC 8.2.0 empfehlen. Damit geht's auf jeden Fall.



  • @HarteWare sagte in <filesystem> gcc 8.1.0:

    Ich hatte mit GCC 8.1.0 und <filesystem> auch mal Probleme ... Ich glaube unter Windows zumindest ist/war das broken. Würde GCC 8.2.0 empfehlen. Damit geht's auf jeden Fall.

    Sicher? Dann ist bei meiner selbst gebauten Version wohl was schief gelaufen, oder es fehlte mir ein weiterer Patch, der noch nicht im offziellen GCC9-Branch integriert ist. Werde mir das die Tage nochmal ansehen. "GCC Version soundso für Windows/MinGW" ist ja nicht immer so klar definiert, da gibt es ja etliche Varianten mit teilweise sehr unterschiedlichen Patches - kann mich jedenfalls an kein offizielles GCC-Quellcode-Release erinnern, das sich ungepatcht auf Anhieb überhaupt für Windows bauen ließ 🙂



  • @Finnegan
    MSYS2:

    MINGW64 ~
    $ g++ -v
    Using built-in specs.
    COLLECT_GCC=C:\msys64\mingw64\bin\g++.exe
    COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/lto-wrapper.exe
    Target: x86_64-w64-mingw32
    Configured with: ../gcc-8.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=ada,c,lto,c++,objc,obj-c++,fortran --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev1, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
    Thread model: posix
    gcc version 8.2.0 (Rev1, Built by MSYS2 project)
    
    


  • @HarteWare Danke, das scheint der Compiler des MSYS2-Projekts zu sein, bei denen schau ich auch immer gerne vorbei um zu sehen, ob ich vielleicht irgendwelche windows-spezifischen Patches vergessen habe. Mein GCC 8.2.0 sollte eigentlich auf dem selben Patch-Stand sein. Dort habe ich auch <filesystem> und die libstdc++fs. Bei obigem Code-Beispiel führt das aber bei meinem GCC wie erwähnt zu Linker-Fehlermeldungen. Ich werde deren GCC mal ausprobieren und schauen, ob es da läuft. Möglich, dass bei meinem Build irgendwas schiefgelaufen ist, oder es sich um Nebenwirkungen anderer Patches handelt.

    Update: Habe jetzt mal den aktuellen GCC des MSYS2-Projekts getestet, leider läuft dieser auf die selben Linker-Fehler wie meine Version:

    $ pacman -S mingw-w64-x86_64-gcc
    ...
    
    $ g++ -v
    Using built-in specs.
    COLLECT_GCC=C:\msys64\mingw64\bin\g++.exe
    COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.2.1/lto-wrapper.exe
    Target: x86_64-w64-mingw32
    Configured with: ../gcc-8-20181123/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=ada,c,lto,c++,objc,obj-c++,fortran --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev1, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
    Thread model: posix
    gcc version 8.2.1 20181123 (Rev1, Built by MSYS2 project)
    
    $ cat test.cpp
    #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;
    }
    
    $ g++ -std=c++17 -lstdc++fs -otest.exe test.cpp
    C:\msys64\tmp\ccvfBIcq.o:test.cpp:(.text+0x1d9): undefined reference to `std::filesystem::__cxx11::directory_iterator::operator*() const'
    C:\msys64\tmp\ccvfBIcq.o:test.cpp:(.text+0x213): undefined reference to `std::filesystem::__cxx11::directory_iterator::operator++()'
    C:\msys64\tmp\ccvfBIcq.o:test.cpp:(.text$_ZNSt10filesystem7__cxx1116filesystem_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt10error_code[_ZNSt10filesystem7__cxx1116filesystem_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt10error_code]+0x93): undefined reference to `std::filesystem::__cxx11::filesystem_error::_M_gen_what()'
    C:\msys64\tmp\ccvfBIcq.o:test.cpp:(.text$_ZNSt10filesystem7__cxx1118directory_iteratorC1ERKNS0_4pathE[_ZNSt10filesystem7__cxx1118directory_iteratorC1ERKNS0_4pathE]+0x28): undefined reference to `std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path const&, std::filesystem::directory_options, std::error_code*)'
    C:\msys64\tmp\ccvfBIcq.o:test.cpp:(.text$_ZNSt10filesystem7__cxx114pathC1IA4_cS1_EERKT_NS1_6formatE[_ZNSt10filesystem7__cxx114pathC1IA4_cS1_EERKT_NS1_6formatE]+0x61): undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
    C:\msys64\tmp\ccvfBIcq.o:test.cpp:(.rdata$.refptr._ZNSt10filesystem7__cxx1116filesystem_errorD1Ev[.refptr._ZNSt10filesystem7__cxx1116filesystem_errorD1Ev]+0x0): undefined reference to `std::filesystem::__cxx11::filesystem_error::~filesystem_error()'
    C:\msys64\tmp\ccvfBIcq.o:test.cpp:(.rdata$.refptr._ZTVNSt10filesystem7__cxx1116filesystem_errorE[.refptr._ZTVNSt10filesystem7__cxx1116filesystem_errorE]+0x0): undefined reference to `vtable for std::filesystem::__cxx11::filesystem_error'
    collect2.exe: error: ld returned 1 exit status
    

    Da scheint also nochwas im argen zu liegen. Ich würde mich sogar zu der Einschätzung hinreißen lassen, dass <filesystem> unter Windows von der libstdc++ derzeit noch nicht vollständg unterstützt wird ... selbst der aktuelle GCC-9-Entwicklungs-Branch hat dasselbe Problem. Es liegt also wahrscheinlich nicht daran, dass nur bei diesem Backport etwas nicht stimmt.

    Update 2: Was mich jetzt wirklich stutzig macht, ist dass selbst mein Windows-zu-Linux-GCC ebenfalls diese Fehler ausspuckt:

    $ x86_64-linux-musl-g++ -std=c++17 -lstdc++fs -otest.exe test.cpp
    C:\Users\XXX~1\AppData\Local\Temp\ccT7c1r7.o: In function `main':
    test.cpp:(.text+0xec): undefined reference to `std::filesystem::__cxx11::directory_iterator::operator*() const'
    test.cpp:(.text+0x125): undefined reference to `std::filesystem::__cxx11::directory_iterator::operator++()'
    C:\Users\XXX~1\AppData\Local\Temp\ccT7c1r7.o: In function `std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path const&)':
    test.cpp:(.text._ZNSt10filesystem7__cxx1118directory_iteratorC2ERKNS0_4pathE[_ZNSt10filesystem7__cxx1118directory_iteratorC5ERKNS0_4pathE]+0x26): undefined reference to`std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path const&, std::filesystem::directory_options, std::error_code*)'
    C:\Users\XXX~1\AppData\Local\Temp\ccT7c1r7.o: In function `std::filesystem::__cxx11::path::path<char [4], std::filesystem::__cxx11::path>(char const (&) [4], std::filesystem::__cxx11::path::format)':
    test.cpp:(.text._ZNSt10filesystem7__cxx114pathC2IA4_cS1_EERKT_NS1_6formatE[_ZNSt10filesystem7__cxx114pathC5IA4_cS1_EERKT_NS1_6formatE]+0x5e): undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
    collect2.exe: error: ld returned 1 exit status
    

    ...muss nochmal weiter unter Linux testen. -lstdc++fs sollte doch eigentlich ausreichen, oder fehlt da noch irgendeine Compiler-Option?

    Update 3: Lustig. Selbes Problem unter einer VM mit Alpine Linux (Edge):

    alpine-vm:~$ g++ -v
    Using built-in specs.
    COLLECT_GCC=g++
    COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-alpine-linux-musl/8.2.0/lto-wrapper
    Target: x86_64-alpine-linux-musl
    Configured with: /home/buildozer/aports/main/gcc/src/gcc-8.2.0/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --build=x86_64-alpine-linux-musl --host=x86_64-alpine-linux-musl --target=x86_64-alpine-linux-musl --with-pkgversion='Alpine 8.2.0' --enable-checking=release --disable-fixed-point --disable-libstdcxx-pch --disable-multilib --disable-nls --disable-werror --disable-symvers --enable-__cxa_atexit --enable-default-pie --enable-default-ssp --enable-cloog-backend --enable-languages=c,c++,objc,fortran,ada --disable-libssp --disable-libmpx --disable-libmudflap --disable-libsanitizer --enable-shared --enable-threads --enable-tls --with-system-zlib --with-linker-hash-style=gnu
    Thread model: posix
    gcc version 8.2.0 (Alpine 8.2.0)
    
    alpine-vm:~$ cat test.cpp
    #include <iostream>
    #include <filesystem>
    
    namespace fs = std::filesystem;
    
    auto main() -> int
    {
        for (auto& entry : fs::directory_iterator("/"))
            std::cout << entry.path() << std::endl;
        return 0;
    }
    
    alpine-vm:~$ g++ -std=c++17 -lstdc++fs -otest test.cpp
    /usr/lib/gcc/x86_64-alpine-linux-musl/8.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: /tmp/ccCcOCBM.o: in function `main':
    test.cpp:(.text+0x100): undefined reference to `std::filesystem::__cxx11::directory_iterator::operator*() const'
    /usr/lib/gcc/x86_64-alpine-linux-musl/8.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: test.cpp:(.text+0x146): undefined reference to `std::filesystem::__cxx11::directory_iterator::operator++()'
    /usr/lib/gcc/x86_64-alpine-linux-musl/8.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: /tmp/ccCcOCBM.o: in function `std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path const&)':
    test.cpp:(.text._ZNSt10filesystem7__cxx1118directory_iteratorC2ERKNS0_4pathE[_ZNSt10filesystem7__cxx1118directory_iteratorC5ERKNS0_4pathE]+0x26): undefined reference to `std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path const&, std::filesystem::directory_options, std::error_code*)'
    /usr/lib/gcc/x86_64-alpine-linux-musl/8.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: /tmp/ccCcOCBM.o: in function `std::filesystem::__cxx11::path::path<char [4], std::filesystem::__cxx11::path>(char const (&) [4], std::filesystem::__cxx11::path::format)':
    test.cpp:(.text._ZNSt10filesystem7__cxx114pathC2IA4_cS1_EERKT_NS1_6formatE[_ZNSt10filesystem7__cxx114pathC5IA4_cS1_EERKT_NS1_6formatE]+0x6d): undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
    collect2: error: ld returned 1 exit status
    

    So langsam glaube ich, dass ich etwas sehr triviales übersehe. GCC sollte doch eigentlich <filesystem> schon länger unterstützen, oder? Hat irgendjemand vielleicht eine Idee was hier schief läuft?

    Update 4: Final facepalm! ... -lstdc++fs natürlich als letzte Compiler-Option. Link-Reihenfolge... zuerst die Libs/Objekte die eine Bibliotheksfunktion benötigen und danach die Bibliotheken linken, welche die Funktionen zur Verfügung stellen. Sorry Leute! So viel Text für so etwas triviales produziert. Jetzt funktionierts auch überall 🙂