DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7AE5B3898004
Mime-Version: 1.0 (1.0)
Subject: Re: g++ and c++17 filesystem
Date: Wed, 18 Nov 2020 22:18:32 +0100
Message-Id: <FD1969EA-9204-4986-BE5E-0C9F45D256B7@gmail.com>
References: <861bc601-876b-e16d-d4f7-0bb543d61d8e@cs.umass.edu>
In-Reply-To: <861bc601-876b-e16d-d4f7-0bb543d61d8e@cs.umass.edu>
To: moss@cs.umass.edu
From: Kristian Ivarsson via Cygwin <cygwin@cygwin.com>
Reply-To: Kristian Ivarsson <sten.kristian.ivarsson@gmail.com>
Cc: cygwin@cygwin.com, =?utf-8?Q?Ren=C3=A9_Berber?= <rene.berber@gmail.com>
Content-Type: text/plain; charset="utf-8"
Sender: "Cygwin" <cygwin-bounces@cygwin.com>
Content-Transfer-Encoding: 8bit


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


> 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