<filesystem> gcc 8.1.0



  • 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



  • Dieser Beitrag wurde gelöscht!


  • Dieser Beitrag wurde gelöscht!


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



  • Dieser Beitrag wurde gelöscht!


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



  • Dieser Beitrag wurde gelöscht!


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



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


Anmelden zum Antworten