DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 335D6386F81D
To: <cygwin AT cygwin DOT com>
References: <c2d6280c-26e3-f9e7-89bd-693385a768b2 AT gmail DOT com>
 <D3704C33-A283-40F0-990D-CB9806F0B09D AT gmail DOT com>
 <000a01d6be5b$3808cad0$a81a6070$@gmail.com>
 <15d2b3e5-cbb8-0008-e99a-3922ff4a5f3b AT SystematicSw DOT ab DOT ca>
In-Reply-To: <15d2b3e5-cbb8-0008-e99a-3922ff4a5f3b@SystematicSw.ab.ca>
Subject: Sv: Sv: g++ and c++17 filesystem
Date: Fri, 20 Nov 2020 10:37:51 +0100
Message-ID: <000801d6bf20$d0ce0670$726a1350$@gmail.com>
MIME-Version: 1.0
Content-Language: en-gb
Thread-Index: AQIMEcHDzo+EBBrhHHj3sFlr53GwtQIBqNbVAy9h9QUBKn/4X6kzNpzQ
From: Kristian Ivarsson via Cygwin <cygwin AT cygwin DOT com>
Reply-To: sten DOT kristian DOT ivarsson AT gmail DOT com
Content-Type: text/plain; charset="utf-8"
Sender: "Cygwin" <cygwin-bounces AT cygwin DOT com>
Content-Transfer-Encoding: 8bit

[snip]
> >> As stated earlier, it seems like using mingw g++/libstdc++ (from the
> >> cygwin-package-manager) it seems like it works better, but then you
> >> can’t mix with other posix/cygwin mechanism (that uses cygstdc++)
> >> without breaking ODR (and probably some memory models etc as well) so
> >> maybe someone do have some insightful info about this ? How “special”
> >> is
> >> cygstdc++ (compared to mingw:s libstdc++) ? Could this be fixable in
> >> cygstdc++ that
> >> library (cygstdc++) ?


> > I might be totally wrong, so does anyone have any take on this ?
> 
> Cygwin provides cross-tools like djgpp-gcc-core mingw64-i686-gcc-core,
> mingw64-x86_64-gcc-core, cygwin32-gcc-core, cygwin64-gcc-core, and djgpp-
> binutils, mingw64-i686-binutils, mingw64-x86_64-binutils, cygwin32-
> binutils, cygwin64-binutils so anyone has the freedom to choose to build
> DOS, Windows, or Cygwin apps targeting their respective APIs, under
> Cygwin, and also have the freedom to give away or sell those apps as long
> as they respect their licences.
> 
> Cygwin's goal is to have everyone and everything believe it is running in
> a POSIX environment and provide interoperability within a Windows
> environment (including Wine) based on POSIX standards, system interfaces,
> toolchains, shells, utilities:
> 
> 	https://pubs.opengroup.org/onlinepubs/9699919799/
> 
> system and network servers and services, plus GUI desktops (GNOME, KDE,
> LXDE, MATE, Plasma, Xfce desktops on X Window System), and apps (task and
> file managers, web browsers, PDF viewers and editors, graphics viewers and
> editors including GIMP). This is all ported and supported by volunteers
> who believe everyone should have a choice, even when for business or
> family reasons they use Windows.

Tnx Brian

I think The Cygwin-community is doing a great job but with some caveats, such as this

We're in need of various posix-libraries and I guess they won't be available if using the mingw-g++/libstdc++ (I guess cygstdc++ is needed then due to some special memory models etc etc etc) ?

I can for sure try it out, but that would be quite cumbersome because the and I guess it'll be a whole lot of hazzle to make it working

I'd rather help out or having a dialog of how to fix std::filesystem, i.e. change the usage of the __CYGWIN__ macro in that implementation, but this seems to be a part of the "real" GCC-distribution o I guess I need to be involved in that open-source-community instead, but I guess it somehow is invoked from this project somehow so I guess some people here do have some real insights about this ?

The whole C/C++ community is striving for total cross-platform libraries (but I guess we have a few years left for that) and std::filesystem was supposed to take us all in that direction and I totally understand that std::filesystem-library in Cygwin do think it is on a posix-filesystem (though it's not) and I totally understand why the behaviour is as it is, but I don't agree that is a good thing, considering that the underlaying posix-implementation already today accepts Windows:ish-like-paths in some circumstances, I'd like the whole package to be even more agnostic because most applications don't have any wish to inspect the content of a path-object no more than the value of a socket-descriptor

Applications might wanna extract type, name, parent-folder, etc but do rarely care about what kind of separator it has (/ or \) and the style of the root directory etc and it would be very neat if the cygwin std::filesystem-library became more agnostic in these regards

Best regards,
Kristian


> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
> 
> This email may be disturbing to some readers as it contains too much
> technical detail. Reader discretion is advised.
> [Data in binary units and prefixes, physical quantities in SI.]
> --
> 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