Re: [boost] Making Boost.Filesystem work with GENERAL filenames with g++ in Windows (a solution)

Subject: Re: [boost] Making Boost.Filesystem work with GENERAL filenames with g++ in Windows (a solution)
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-10-26 16:28:28

On Wed, Oct 26, 2011 at 5:47 AM, Artyom Beilis <artyomtnk_at_[hidden]> wrote:
> ----- Original Message -----
>> From: Alf P. Steinbach <alf.p.steinbach+usenet_at_[hidden]>
>>
>> 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