Subject: Re: [boost] [filesystem][cygwin] Standard conformance for wide characters
From: Beman Dawes (bdawes_at_[hidden])
Date: 2009-01-14 08:56:32
On Tue, Jan 13, 2009 at 1:17 PM, Emil Dotchevski
> On Tue, Jan 13, 2009 at 6:16 AM, Beman Dawes <bdawes_at_[hidden]> wrote:
>> I've decided not to attempt support for Cygwin in the next version of
> I pulled the plug on Cygwin support at my company a couple of years
> ago for the lack of wchar_t support. They ought to support it.
Since in this case Cygwin is just a packager of other people's work,
it isn't on their radar screen.
I doubt it would take much work to add gcc wide character support; the
compiler already supports wchar_t as does the C++ standard library.
IIUC, the only piece of the puzzle that is missing is the C language
library support. I suspect any of us could code that up in short
order, but I don't want to take the time to figure out how to
integrate it into their build system and sheppard the changes through
>> Cygwin's lack of library support for wchar_t is the problem . For the
>> current Boost.Filesystem version (v2), the necessary workarounds are so
>> pervasive that the implementation code is much harder to read and maintain.
> Is it true that had the interface of boost::filesystem been defined in
> terms of utf8, then the only platform on which wchar_t support would
> have been instrumental is Windows, and we wouldn't have had problems
> with Cygwin?
The problem isn't so much the interface as the internals. Windows'
native character type for file names is wchar_t.
>> IIUC, the reason Cygwin doesn't provide C++ standard library support for
>> wchar_t is that the underlying C library is missing the C wchar_t functions.
>> Perhaps Boosters who care about Cygwin could spearhead an effort to add the
>> missing C support?
> You're right that it's missing the needed C library functions, but I
> was able to hack into the C++ headers to trick them to support
> std::wstring anyway. That's not the same as full wchar_t support, but
> it was the only thing I personally cared about.
> My hack broke with one of the Cygwin releases that followed and I gave
> up on tracking down why, but I suppose if someone cares enough about
> this it can be done (my approach was to inject a modified version of
> one of the gcc-specific header files into the compiler include path,
> I'm not sure if this would be good enough for Boost.)
I suspect it is far easier to just fix the problem at the Cygwin
source code level that trying to hack and maintain patches for Cygwin
object code distributions.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk