From: Jonathan Yong <10walls@gmail.com>
To: cygwin@cygwin.com
Subject: Re: Sv: Sv: g++ and c++17 filesystem
Date: Fri, 20 Nov 2020 18:28:37 +0000 [thread overview]
Message-ID: <9e881c01-e883-ecd5-883a-e1ac55c740c7@gmail.com> (raw)
In-Reply-To: <000201d6bf17$7cc4beb0$764e3c10$@gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 3548 bytes --]
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.
[-- Attachment #1.1.2: OpenPGP_0x713B5FE29C145D45_and_old_rev.asc --]
[-- Type: application/pgp-keys, Size: 8035 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2020-11-20 18:28 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-17 15:15 sten.kristian.ivarsson
2020-11-17 16:45 ` René Berber
2020-11-18 9:00 ` Sv: " sten.kristian.ivarsson
2020-11-18 16:24 ` René Berber
2020-11-18 16:31 ` Eliot Moss
2020-11-18 20:46 ` Kristian Ivarsson
2020-11-18 20:56 ` Eliot Moss
2020-11-18 21:18 ` Kristian Ivarsson
2020-11-18 23:47 ` Eliot Moss
2020-11-19 8:10 ` Sv: " sten.kristian.ivarsson
2020-11-18 21:45 ` Norton Allen
2020-11-19 0:08 ` Doug Henderson
2020-11-19 6:23 ` Brian Inglis
2020-11-19 10:03 ` Sv: " sten.kristian.ivarsson
2020-11-19 15:27 ` Brian Inglis
2020-11-20 9:37 ` Sv: " sten.kristian.ivarsson
2020-11-20 15:29 ` Brian Inglis
2020-11-20 16:11 ` Sv: " sten.kristian.ivarsson
2020-11-19 15:36 ` Eliot Moss
2020-11-20 8:31 ` Sv: " sten.kristian.ivarsson
2020-11-20 18:28 ` Jonathan Yong [this message]
[not found] ` <000601d6c173$aa55d540$ff017fc0$@gmail.com>
2020-11-23 11:09 ` Sv: " Jonathan Yong
2020-11-24 9:32 ` Sv: " sten.kristian.ivarsson
2020-11-24 10:24 ` Jonathan Yong
2020-11-24 11:35 ` Sv: " sten.kristian.ivarsson
2020-11-24 12:33 ` Jonathan Yong
2020-11-24 14:01 ` Sv: " sten.kristian.ivarsson
2020-11-25 2:25 ` Jonathan Yong
2020-11-24 13:22 ` Eliot Moss
2020-11-24 14:31 ` Sv: " sten.kristian.ivarsson
2020-11-24 20:06 ` Ken Brown
2020-11-24 20:39 ` Eliot Moss
2020-11-25 8:02 ` Sv: " sten.kristian.ivarsson
2020-11-25 8:30 ` sten.kristian.ivarsson
2020-11-25 0:23 ` Brian Inglis
2020-11-25 9:00 ` Sv: " sten.kristian.ivarsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9e881c01-e883-ecd5-883a-e1ac55c740c7@gmail.com \
--to=10walls@gmail.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).