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. ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public