[Mingw-w64-public] Windows/MinGW extension: opening std::fstream with a wstring/wchar_t*

[Ruben Van Boxem]

2011/6/26 Jonathan Wakely <jwakely.gcc@gmail.com>:
> On 26 June 2011 16:26, Jonathan Wakely wrote:
>> On 26 June 2011 16:06, Ruben Van Boxem wrote:
>>>
>>> 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.
>
> N.B. it should be _GLIBCXX with a single underscore, not two.
>

That was the plan of course :). I attached a new patch, which
incorporates a configure check, fixes whitespace issues, and moved the
new symbol exports to the latest GCC 4.7 libstdc++ version block. I
hope that the fact that these symbols are only available on Windows
(and thus absent on any other platform) won't break the build if
they're specified in the gnu.ver file.

2011/6/26 Sam Morris <sam@robots.org.uk>:
> FYI, I think you can do this without modifying the fstream like this:
>
> __gnu_cxx::stdio_filebuf b (_wopen (L"filename", _O_RDONLY));
> std::istream i (&b);
>
> The stdio_filebuf will close the file when it's done.
>
> stdio_filebuf can also be constructed given a FILE* argument, which lets
> you open the file with _wfopen; however in this case it won't close the
> FILE* when it is destroyed.

Let me start by saying I mean no offence ;-) __gnu_cxx hacks is
exactly what I'm trying to avoid. I think my idea has true added value
due to it also being in "the other big STL" for the Windows platform
(If it is liked here, I see no reason not to also propose it to LLVM's
libc++). The new function overloads make writing cross-platform code
(by which I mean Windows and other POSIX compliant platforms) a lot
easier and a lot less convoluted. One can typedef a string class, and
use that throughout the program, without having to worry about opening
files with unicode filenames. The fact that you suggest this really
shows that this is a problem not simply worked around in a Standards
compliant fashion. Well then, I say fix the implementation to what is
only a logical extension.

Once the patch in its working form is approved, I can add a Changelog
entry (or if someone wants to be nice, please feel free :))

Thanks!

Ruben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fstream_wchar_t.patch
Type: application/octet-stream
Size: 20807 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20110627/8aca23e4/attachment.obj>