Subject: Re: [boost] cygwin API: posix or windows
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-01-07 09:28:44
On Thu, Jan 6, 2011 at 4:32 PM, vicente.botet <vicente.botet_at_[hidden]> wrote:
> while trying to make Boost.System and Boost.Chrono configurable header only libs we need to include windows.h on some include files. To avoid the inclusion of this intrusive file, we decided sometime ago to include some files in detail/win that will present just the needed interfaces.
> In my humble opinion cygwin is a wrapper of posix intefaces under windows OS.
Cygwin is a distribution, not an API. The Cygwin distribution includes
both the POSIX API and, via MinGW, the Windows API.
<aside> The POSIX API is implemented by calling the Windows API, so is
really only an emulation of POSIX. It does a great job, but is weak in
a few areas, such as permissions, where the Windows API doesn't allow
100% emulation of POSIX. </aside>
> So, boost libraries shouldn't use Windows interfaces when working under cygwin.
That doesn't follow. A primary use of Cygwin is simply to gain access
to GCC on Windows, without any intent to ever port code to POSIX
systems, and without any interest in, or knowledge of, the POSIX API.
This use has become more popular as GCC has jumped far ahead of VC++
in terms of C++0x support.
Another primary use of Cygwin is to gain access to GCC and the POSIX
API on Windows, but that doesn't imply anything about what Boost
implementations should do.
> What's the experience of others?
Boost.Filesystem V2 implementation code provided an option on Windows
of compiling under GCC using the POSIX API. It was difficult to test,
rarely worked well, was a source of confusion, and wasted too much of
my time. So Filesystem V3 and Boost.System dropped any pretense of
compiling with the POSIX API on Windows. There have been no complaints
Boost.System only uses a very few O/S API calls, so it would be
relatively easy to compile for the Cygwin supplied POSIX API on
Windows. But there have been no requests, so far.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk