public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: <sten.kristian.ivarsson@gmail.com>
To: <cygwin@cygwin.com>
Subject: Sv: Sv: g++ and c++17 filesystem
Date: Fri, 20 Nov 2020 10:37:51 +0100	[thread overview]
Message-ID: <000801d6bf20$d0ce0670$726a1350$@gmail.com> (raw)
In-Reply-To: <15d2b3e5-cbb8-0008-e99a-3922ff4a5f3b@SystematicSw.ab.ca>

[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


  reply	other threads:[~2020-11-20  9:37 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             ` sten.kristian.ivarsson [this message]
2020-11-20 15:29               ` Sv: " 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
     [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='000801d6bf20$d0ce0670$726a1350$@gmail.com' \
    --to=sten.kristian.ivarsson@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).