
Jeff Garland wrote:
On Sun, 15 Feb 2004 15:37:14 -0500, Edward Diener wrote
Paul Miller wrote:
I just started using boost recently and it seems excellent so far.
One of the first classes I started using is filesystem::path, with the intention to use it portably on Windows, OS X, and Linux.
On Windows and OS X, you can work with paths in Unicode. Presumably Linux still works with multi-byte characters.
Is there progres toward a wchar_t-aware path?
I don't know if Mr. Dawes will include such an addition in a future version of filesystem, but I do know that urging that C++ standard libraries add wide character filenames and paths where appropriate, on comp.std.c++, has met with a wall of resistance in the past. There
Of course, given that boost is open source, there is always another path. The users that really want wchar_t support can dig in and work on coming up with a design / implementation. I'm sure Beman and others would welcome such contributions and are willing to help discuss the design options.
Having just finished (checked in today) adding wide string/stream support into date_time, I can tell you it is a non-trivial issue. The fundamental problem traces back to those legacy compiler/library combinations. My goal wasn't to support wide string/streams on the legacy platforms, only to not break the current level library support for those compilers. That was tricky without hacking up the code base too badly. So I would council patience on the part of folks that aren't willing to spend the time to work out a concrete proposal for how to approach the problem.
I think there are two separate issues which shouldn't be mixed, and I don't know if you are inadvertently mixing them by your remark. One is support for wide character file names, and the other is support for wide character file streams. The C++ standard library does support wide character file streams, it just doesn't support wide character file names. I wasn't in any way criticizing filesystem for not having support for wide character file names, or even supposing that it should support wide character file names. In fact I don't think it should unless the C++ standard library supported wide character file names in its basic_fstream template classes, which it doesn't. As far as a proposal for the C++ standard library supporting wide character file names, I did not make one for a number of reasons, one of which is that the feeling against it, from comp.std.c++, of leading C++ standard committee members was so strong that I did not feel it to be worthwhile even though I disagreed with them and argued my disagreement there. Finally I think that adding wide character file name support to the C++ standard library is a much different issue from adding it to filesystem, with adding it to filesystem being a much more complicated endeavor than adding it to the C++ standard library classes. But that may be a discussion which really doesn't belong here, since it doesn't really deal with filesystem but with my opinion about how to add wide character file name support to the C++ standard library.