Sv: Sv: g++ and c++17 filesystem

[Jonathan Yong]

On 11/20/20 8:31 AM, Kristian Ivarsson via Cygwin wrote:
>> 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)
> 

That is not correct, \ is a valid filename under *nix, but not on 
Windows. I don't think the standards specify what filenames or character 
sets are valid. Cygwin strives for *nix compatibility, anything else is 
secondary.

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

Cygwin is not Windows, it runs on Windows, but it is not Windows. You 
should use mingw if you want Windows style paths. There isn't a magical 
tool that allows you to have it both ways.

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

If you use Cygwin, you are expected to use *nix paths, not Windows 
paths. Windows paths may work but are not supported overall, as Windows 
is not POSIX. If you want Windows, then use mingw or MSVC. Since you 
mentioned it is not possible to use mingw, then that will leave you with 
only MSVC, your only possible choice is now clear.

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

Yes, cross platform, you can use std::filesystem on Linux, Cygwin, 
Windows, Macs, but it certainly cannot do anything that can't be handled 
for the underlying platform. For Cygwin, it means using *nix paths, not 
Windows.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x713B5FE29C145D45_and_old_rev.asc
Type: application/pgp-keys
Size: 7929 bytes
Desc: not available
URL: <https://cygwin.com/pipermail/cygwin/attachments/20201120/739698d0/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://cygwin.com/pipermail/cygwin/attachments/20201120/739698d0/attachment-0001.sig>