On Tue, Jan 13, 2009 at 6:16 AM, Beman Dawes <bdawes@acm.org> wrote:
I've decided not to attempt support for Cygwin in the next version of Boost.Filesystem.
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.
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?
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.) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode