> Ok, first, I admit that I was not familiar with the details of > std::filesystem. However, after looking at it, I remain unsurprised that > the Cygwin and Mingw versions might be different. (I would also not be > surprised if there is a real bug in there.)
At least semantic bugs considering the whole concept > The behavior I would _expect_ is that the Cygwin version will work using Posix sorts of assumptions. I guess it will to, but then your application have to ensure that in every place the application uses a file path and the reasons we do have (platform-independent) libraries is to not having to do that > While a root of C: (for example) _might_ work, /cygdrive/c is more > normative on Cygwin. Yes, but to what purpose ? What applications do explicitly handle any root directory (except for possibly /tmp or /dev/null) ? (I put a link to that in Cygwin's / called c, so > that, for me, /c works.) Likewise, I would expect the normative path > separator to be / not \, and an absolute path to start with /. Windows > offers several kinds of symlinks, with varying semantics, so the detailed > behavior of that would be affected by the settings in the CYGWIN > environment variable All the implementations of std::filesystem I've seen so far, is agnostic to whether / or \ is used as a path separator (but the generic form is '/' and a fun fact, the MSVC-implementation of std::filesystem handles the generic (posix) form more close to the standard specification than GCC) > I would expect std::filesystem to present paths to construct paths to > present to underlying library calls such as open ... and on Cygwin, open > uses Posix style paths. I consider that to be a mistake in the implementation of std::filesystem, because on Windows the preferred style would be smt like C:/ and then as an opt-out it would consider /cygdrive/c (or such) as a valid thing as well > I "get" that you want to write portable programs that use this interface, > which is analogous to the Java file path classes. In terms of how this > interface works, I would expect it to _claim_ that it is Posix, not > Windows, because the paths Cygwin supports are Posix style (it _will_ > recognize a few Windows idioms, but it is correct in not advertising > itself as Windows). > > So it you want to do Windows-style (but abstracted with this library), I > direct you to Mingw. Each has its place. Cygwin allows one to pretend, > pretty successfully though with a few small rough edges, that one is on > Linux, not Windows. That is its intent. Mingw gives you the gcc/gnu > toolchain and libraries under Windows. As stated earlier, we're using Cygwin to be able to keep some kind of cross platform code base and Cygwin offers non-cross-platform-standardized libraries/api:s (i.e. posix) to be executable without having to #ifdef the code base to be buildable and executable on Windows but MinGW doesn't supply those posix libraries on Windows (maybe a few), so using GCC/MinGW is not an option and I guess we'd go with MSVC if we wanted to port our code completely std::filesystem is supposed to be cross-platform (and easier to use than various posix-library-C-functions) though and it is cross-platform per definition but, then again, not when using Cygwin > I hope we're not still talking at cross purposes, though that it certainly > possible! > > Best wishes - EM > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation: https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple