On Wed, Oct 26, 2011 at 5:47 AM, Artyom Beilis <artyomtnk@yahoo.com> wrote:
----- Original Message -----
From: Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com>
First, apologies if I'm posting to the wrong group/list; if so then please redirect me.
IMHO access to files is a crucial part of Boost.Filesystem. However, with Boost 1.47, and using g++ 4.4.1 in Windows 7, boost::filesystem::ifstream etc. fail to open or create files with non-ANSI characters. It works fine with Visual C++; it FAILS with g++ 4.4.1, which is the one bundled with the Code::Blocks IDE.
The failure probably has nothing to do with the g++ version: it's due to g++ not offering the Visual C++ wchar_t oriented extensions to the standard iostreams (Boost.Filesystem uses these Visual C++ extensions).
I stumbled onto this while I was writing about using Unicode in C++ programming in Windows.
Why just not to implement boost::filesystem::fstream over _wfopen and custom streambuf implementation?
It is relatively simple.
It always seemed to me that a custom streambuf implementation would be hard to support in that users would expect it to exactly mimic the native library's implementation, bugs and all.
Using short file names is no go for two reasons:
1. It works only when file exists (can't create new file)
The Filesystem V2 hack used the Windows wide API for file create, so the fstream implementation only ever saw an existing file.
2. It is quite deprecated
8.3 support can be turned off, so is problematic. A patch to libstdc++ would be much cleaner, and would benefit users beyond just the Boost community, IMO. --Beman