Sv: g++ and c++17 filesystem
Thu Nov 19 08:10:25 GMT 2020

> >> I would agree that if you want an executable that acts and feels more
> like a Windows native application, then mingw is probably what you want.
> Cygwin is if you want something that acts and feels more like a Posix
> thing ... which means it will be oriented to Posix style paths.
> > To be able to use mingw all the code have to be ported to use Windows
> > native mechanisms and then we might just use MSVC instead
> >
> > We don’t want (either) Windows-style-paths or Posix-style-paths, we
> > want A path and expect it to work equally regardless of what platform
> > is used in regards to std::filesystem
> >
> > As far as I see, very few applications do form their own - and/or have
> > hard-coded absolute paths and instead they are usually input data
> > (through UI, configuration, OS, environment or such)
> IN this context, I would say "Which std::filesystem?  The Cygwin Posix-
> like one or the mingw Windows-like one?"  If you want uniformity, I'd go
> with Cygwin; it you want platform-like behavior, then mingw.

I'm referring to std::filesystem as a part of the C++17 standard ( that is pretty well defined and quite agnostic to what "style" of path used as our application are and as I said, we don't care (we don't ever inspect them) what "style" of paths we're using but we expect a deterministic behaviour from that library regardless of operating system, such as and absolute path should be an absolute path regardless

That's the sole purpose of std::filesystem, i.e. to be platform independent (though all file-features is not applicable on all operating systems, but at least you can ask the library for those attributes)

GCC/MinGW support platform-INDEPENDENT-behaviour because gcc/g++ works equally regardless if Linux or Windows in regards to std::filesystem

Best regards,

> Best wishes - EM
> --
> Problem reports:
> FAQ:        
> Documentation:
> Unsubscribe info:

More information about the Cygwin mailing list