This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Windows/MinGW extension: opening std::fstream with a wstring/wchar_t*
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: vanboxem dot ruben at gmail dot com
- Cc: libstdc++ at gcc dot gnu dot org, mingw64 <mingw-w64-public at lists dot sourceforge dot net>
- Date: Sun, 26 Jun 2011 16:26:09 +0100
- Subject: Re: Windows/MinGW extension: opening std::fstream with a wstring/wchar_t*
- References: <BANLkTindNmsKgyhWyr7M4x9UJJrY7i4rPg@mail.gmail.com>
On 26 June 2011 16:06, Ruben Van Boxem wrote:
> Hi,
>
> I have implemented a small patch that mirrors Microsoft's STL
> extension, where one can use wide strings as an argument to
> std::(w)fstream. This is very useful on Windows, where, without this
> extension, there is no way to open an fstream for a filename
> containing non-ASCII characters not in the Windows local codepage. The
> workaround would be to subclass a streambuf to accept a wchar_t*
> filename, but I think a lower-level fix (ie on library level) is much
> more suitable, and provides more robustness. In the C API provided by
> Microsoft in their MSVCRT (catered for by MinGW(-w64)), a function
> _wfopen, which imitates plain fopen, but accepts wchar_t* arguments
> for the exact purpose I use it in my patch. Documentation for _wfopen
> is here:
> http://msdn.microsoft.com/en-us/library/yeby3zcb%28v=VS.100%29.aspx
>
> No extra #includes are necessary, and for now I #ifdef'ed the extra
> code with #if _WIN32. Perhaps cleaner would be a configure check for
> OS or CRT used and a __GLIBCXX* macro to enable this functionality.
I think that would be better.
> I understand the patch is not complete (no Changelog, etc...), but I
> would like to know your thoughts on how I implemented this
> functionality. The changes:
> ?- libstdc++-v3/config/io/basic_file_stdio.cc: wfopen_mode: new
> function, copy of fopen_mode, but returns wchar_t*
> ?- libstdc++-v3/config/io/basic_file_stdio.cc:
> __basic_file<char>::open: new overload, taking wchar_t* argument, and
> uses new wfopen_mode and Windows' _wfopen instead of plain fopen.
> ?- libstdc++-v3/config/io/basic_file_stdio.h: open: new overload
> taking wchar_t* argument
> ?- libstdc++-v3/include/bits/fstream.tcc: open: new overloads, taking
> wchar_t* argument
> ?- libstdc++-v3/include/std/fstream: open: new overloads taking
> wchar_t* and if C++0x is enabled, also overloads taking a std::wstring
> ?- libstdc++-v3/config/abi/pre/gnu.ver: modify regex statements to
> also include new symbols.
You cannot add the new symbols to the old versions, they must be
versioned using a new version, not an old one that has already been
released. You can't change the symbols exported by a released library
version.
> Simple testing of the functionality works as it should. I first
> modified GCC trunk, created a patch, and applied that to the 4.6
> branch. Conclusion: this change should work for GCC 4.6 and up for
> sure, maybe even 4.5. As it stands, only Windows is affected, and
> should be affected. Perhaps systems where Unicode filenames aren't
> UTF-8 (oh wait: that's pretty much Windows only) could also benefit
> from this.
As a new feature I think this would only be suitable for trunk (i.e. 4.7)
There are some formatting issues with whitespace (missing blank lines,
#ifdef _WIN32 should not be indented with the code) but generally I
think the patch is a good idea. I don't know enough about the Windows
API to feel confident approving the change though.