Windows/MinGW extension: opening std::fstream with a wstring/wchar_t*

[Ruben Van Boxem]

2011/6/27 Jonathan Wakely <jwakely.gcc@gmail.com>:
> On 27 June 2011 21:19, Paolo Carlini wrote:
>> Hi,
>>
>> to be really honest, I'm not sure I like the idea of adding all this code
>> only to enable such an extension benefiting only Windows/MinGW. By the way,
>> submitter himself noticed that subclassing is another viable option.
>
> After reading the issue I find the rationale for closing 454 as NAD to
> be quite convincing, a TR2 filesystem library would be a better
> solution than adding constructors which are only present on some
> platforms.
>
>> At minimum, let's look forward some feedback from the maintainers of the
>> Cygwin / MinGW ports...

Although the maintainers are not answering here, I have contacted both
mingw projects' mailing lists and the responses have been only
positive.

Kai likes the idea, and several mingw users would be relieved to
finally have this in GCC's libstdc++ so they can stop hacking around
it.

>
> I suppose the MinGW port could always add the code, so it doesn't need
> to be in upstream GCC.
>

This would be against the efforts of the MinGW projects. And make it
very hard to guarantee the availability in every GCC build. Windows
isn't Linux, there's no nice packaging infrastructure.

Note TR2 (the filesystem path iostream overload) is not really an
option for the next 5 years. C++0X support is still experimental, and
that standard has an FDIS document. TR2 isn't even finished. The
standards committee clearly "rejected" the addditional overloads,
because they can think long-term. C++ developers writing
Windows/cross-platform code are writing code now, and Windows code
written with Visual Studio makes use of these functions.
Maintenance of this addition is low: the new functions are exact
copies of the old ones, with the minor change of type and
fopen->_wfopen.

Please reconsider the harsh rejection in favor of the many Windows
users that like this fine C++ Standard library.

Ruben