status of wchar_t support in filesystem::path?
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? Is there an existing strategy for storing my Unicode Windows/Mac paths as UTF-8 with the existing path? I notice the existing posix checks would fail horribly in this case. Is a UTF-8 checker in order?
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 seems to be the idea there that just because Windows supports wide character filenames and directories is no reason to have it supported in the C++ standard libraries. Given that the C++ standard committee is so intent on not supporting wide character filenames, I certainly wouldn't fault Mr. Dawes for not doing so. However if he investigates the issue and decides to do it, or if anyone in Boost decides to do work on it, maybe they can pass on their knowledge of its effectiveness and implementation to the C++ standard committee. I am not trying to start another discussion of this issue here on Boost, having spent enough fruitless time in the past arguing for wide character filenames on comp.std.c++, but I thought at least clarifying why boost::filesystem may not support it might be helpful to you.
"Edward Diener" <eddielee@tropicsoft.com> writes:
the C++ standard committee is so intent on not supporting wide character filenames
Be careful about your generalizations. I doubt you've polled the standard committee's members or have any good idea about their intention in this matter. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Edward Diener" <eddielee@tropicsoft.com> writes:
the C++ standard committee is so intent on not supporting wide character filenames
Be careful about your generalizations. I doubt you've polled the standard committee's members or have any good idea about their intention in this matter.
I made it very clear that my idea about their intention was based on my conversation with others in the comp.std.c++ threads. There it was definitely a solid resistance to the idea.
"Edward Diener" <eddielee@tropicsoft.com> writes:
David Abrahams wrote:
"Edward Diener" <eddielee@tropicsoft.com> writes:
the C++ standard committee is so intent on not supporting wide character filenames
Be careful about your generalizations. I doubt you've polled the standard committee's members or have any good idea about their intention in this matter.
I made it very clear that my idea about their intention was based on my conversation with others in the comp.std.c++ threads. There it was definitely a solid resistance to the idea.
The posters on comp.std.c++ are by no means a representative cross-section of committee members. -- Dave Abrahams Boost Consulting www.boost-consulting.com
At 04:06 PM 2/15/2004, David Abrahams wrote:
"Edward Diener" <eddielee@tropicsoft.com> writes:
the C++ standard committee is so intent on not supporting wide character filenames
Be careful about your generalizations. I doubt you've polled the standard committee's members or have any good idea about their intention in this matter.
Exactly. It sounds like Edward has been talking to a C++ standards committee from a parallel universe. The C++ committee from this universe has never had a proposal before it to support wide-character filenames. The LWG has never even formally discussed what path internationalization might look like, AFAICR, although there has been occasional informal discussion between members. Several LWG members are interested in finding solutions to the issues raised by the internationalization of paths, and have contributed support and ideas to Boost.Filesystem's internationalization. --Beman
Beman Dawes wrote:
At 04:06 PM 2/15/2004, David Abrahams wrote:
"Edward Diener" <eddielee@tropicsoft.com> writes:
the C++ standard committee is so intent on not supporting wide character filenames
Be careful about your generalizations. I doubt you've polled the standard committee's members or have any good idea about their intention in this matter.
Exactly.
It sounds like Edward has been talking to a C++ standards committee from a parallel universe.
I don't think this sort of put-down is necessary. I can get just as clever, or nasty, in attempting to put you down on this NG, but I don't think cleverness or nastiness is worth much compared to thought and creativity. If you think I am lying, just say so. While I respect your talents as a programmer, they don't warrant arrogance when dealing with others who have a different opinion than you do. I have never talked to a C++ standards committee, nor have claimed to. I did converse with more than one committee member about this issue on comp.std.c++. If that is what your statement above is supposed to mean, I can assure you that the parallel universe is a real one and it is ours. Regarding the C++ standards committee not being in favor of wide character filenames, I quote from your own FAQ on filesystem. "The C++ standards committee Library Working Group discussed this in some detail both on the committee's library reflector and at the Spring, 2002, meeting, and feels that (1) names based on types other than char are extremely non-portable, (2) there are no agreed upon semantics for conversion between wide-character and narrow-character names for file systems which do not support wide-character name, and (3) even the committee members most interested in wide-character names are unsure that they are a good idea in the context of a portable library." I interpret this to mean that the commitee was not in favor of adding wide character file name support to the C++ standard library. In my discussions on comp.std.c++, particularly with Mr. Plauger, I was more or less told that the committee had already made up its mind not to support wide character file names. He was pretty intolerant to the thought that wide character file names should be added with the proviso that their meaning should be implementation defined. I tried to argue that narrow character file names are implementation defined, since nowhere that I have ever found in the C++ standard document is there any meaning placed on the sequence of chars which make up a narrow character file name, but he didn't believe that this argument was substantive. BTW I wasn't the only one presenting an opinion that wide character file names should be added to the C++ standard library basic_fstream classes. I do realize that you subsequently write that "[October, 2002 - PJ Plauger has suggested a locale based conversion scheme. Others have indicated support for such an experiment.]" As far as you filesystem library is concerned, I believe the issue is very different. You have rightly attempted to come up with a portable syntax for file names, and adding wide character file name support would mean that the issue of a syntax for such a file name, and its meaning and operation on operating systems or implementations which don't support wide character file names, has to be decided by your library.
The C++ committee from this universe has never had a proposal before it to support wide-character filenames.
I never claimed they did. But since they essentially made up their mind against it, or indicated support for a locale based conversion scheme, I didn't pursue any further attempts to argue for my own opionion, or submit a proposal for it.
The LWG has never even formally discussed what path internationalization might look like, AFAICR, although there has been occasional informal discussion between members. Several LWG members are interested in finding solutions to the issues raised by the internationalization of paths, and have contributed support and ideas to Boost.Filesystem's internationalization.
I think that is great but my comments were not intended to be about the internationalization of paths but rather about support for wide character file names in the C++ standard library basic_fstream class ( and message facet ). IMHO these are two separate issues, but I can understand if others disagree and view them as the same issue.
Edward Diener wrote: [...]
In my discussions on comp.std.c++, particularly with Mr. Plauger, I was more or less told that the committee had already made up its mind not to support wide character file names. He was pretty intolerant to the thought that wide character file names should be added with the proviso that their meaning should be implementation defined.
You might be interested in the upcoming LWG Issue #454: basic_filebuf::open should accept wchar_t names [27.8.1.3] Bill Plauger 30 Jan 2004 basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode); should be supplemented with the overload: basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode); Depending on the operating system, one of these forms is fundamental and the other requires an implementation-defined mapping to determine the actual filename.
Peter Dimov wrote:
Edward Diener wrote:
[...]
In my discussions on comp.std.c++, particularly with Mr. Plauger, I was more or less told that the committee had already made up its mind not to support wide character file names. He was pretty intolerant to the thought that wide character file names should be added with the proviso that their meaning should be implementation defined.
You might be interested in the upcoming LWG Issue #454:
basic_filebuf::open should accept wchar_t names [27.8.1.3] Bill Plauger 30 Jan 2004
basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
should be supplemented with the overload:
basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
Depending on the operating system, one of these forms is fundamental and the other requires an implementation-defined mapping to determine the actual filename.
Is there a place on the Internet where I can track this without being a committee member ? I am interested in the outcome to this, and contributing comments if possible. Also is the intent of this that basic_fstream<>::open(const wchar_t *, ios_base::open_mode) be supported also, or is this an implied outcome of the above ?
is there any chance that we'll see: basic_filebuf *basic_filebuf::open(std::string const&, ios_base::open_mode); and of course ...wstring... if the other is adopted? At Monday 2004-02-16 06:56, you wrote:
Edward Diener wrote:
[...]
In my discussions on comp.std.c++, particularly with Mr. Plauger, I was more or less told that the committee had already made up its mind not to support wide character file names. He was pretty intolerant to the thought that wide character file names should be added with the proviso that their meaning should be implementation defined.
You might be interested in the upcoming LWG Issue #454:
basic_filebuf::open should accept wchar_t names [27.8.1.3] Bill Plauger 30 Jan 2004
basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
should be supplemented with the overload:
basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
Depending on the operating system, one of these forms is fundamental and the other requires an implementation-defined mapping to determine the actual filename.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
At 05:29 PM 2/19/2004, Victor A. Wagner, Jr. wrote:
is there any chance that we'll see: basic_filebuf *basic_filebuf::open(std::string const&, ios_base::open_mode); and of course ...wstring... if the other is adopted?
A lot of people have asked for such overloads. It is always hard to tell what might or might not be accepted, until there is a firm proposal in the form of a committee document. Sometimes killer arguments surface which torpedo seemingly innocuous proposals - you never know 'til you try. The documents for next month's meeting should be available any day now. See if there is anything about the issue in the issues list or any proposals. If not propose it yourself. If you can't come to C++ committee meetings, don't let that stop you. A number of critical portions of the Library TR were proposed by John Maddock or Peter Dimov, and neither of them has ever come to a committee meeting AFAIK. Look at past proposals and issues to see the form. --Beman
Beman Dawes wrote:
At 05:29 PM 2/19/2004, Victor A. Wagner, Jr. wrote:
If you can't come to C++ committee meetings, don't let that stop you. A number of critical portions of the Library TR were proposed by John Maddock or Peter Dimov, and neither of them has ever come to a committee meeting AFAIK. Look at past proposals and issues to see the form.
Where does the information about the C++ standard commitee meetings exist ?
At 11:24 PM 2/19/2004, Edward Diener wrote:
Beman Dawes wrote:
At 05:29 PM 2/19/2004, Victor A. Wagner, Jr. wrote:
If you can't come to C++ committee meetings, don't let that stop you. A number of critical portions of the Library TR were proposed by John Maddock or Peter Dimov, and neither of them has ever come to a committee meeting AFAIK. Look at past proposals and issues to see the form.
Where does the information about the C++ standard commitee meetings exist ?
Go to http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/ Click on the most recent "post-" mailing entry. Select the "Minutes of ISO WG21 Meeting" paper, and look for a section entitled "Future meetings" near the end. For the Kona minutes, that entry shows: March 21-26, 2004: Sydney, Australia. Host is Whitesmiths Australia. October 17-22, 2004: Redmond, Washington. Host is Microsoft. Spring 2005 (dates TBA): Oslo, Norway. Fall 2005 (dates TBA): Sydney, Nova Scotia, Canada. --Beman
Beman Dawes wrote:
Beman Dawes wrote:
At 05:29 PM 2/19/2004, Victor A. Wagner, Jr. wrote:
If you can't come to C++ committee meetings, don't let that stop you. >> A number of critical portions of the Library TR were
At 11:24 PM 2/19/2004, Edward Diener wrote: proposed by John >> Maddock or Peter Dimov, and neither of them has ever come to a >> committee meeting AFAIK. Look at past proposals and issues to see the >> form.
Where does the information about the C++ standard commitee meetings
exist ?
Go to http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/
Click on the most recent "post-" mailing entry.
Select the "Minutes of ISO WG21 Meeting" paper, and look for a section entitled "Future meetings" near the end.
For the Kona minutes, that entry shows:
March 21-26, 2004: Sydney, Australia. Host is Whitesmiths Australia. October 17-22, 2004: Redmond, Washington. Host is Microsoft. Spring 2005 (dates TBA): Oslo, Norway. Fall 2005 (dates TBA): Sydney, Nova Scotia, Canada.
Found it. Thanks !
At 12:43 AM 2/16/2004, Edward Diener wrote:
I have never talked to a C++ standards committee, nor have claimed to. I did converse with more than one committee member about this issue on comp.std.c++. If that is what your statement above is supposed to mean, I can assure you that the parallel universe is a real one and it is ours.
Regarding the C++ standards committee not being in favor of wide character filenames, I quote from your own FAQ on filesystem.
"The C++ standards committee Library Working Group discussed this in some detail both on the committee's library reflector and at the Spring, 2002, meeting, and feels that (1) names based on types other than char are extremely non-portable, (2) there are no agreed upon semantics for conversion between wide-character and narrow-character names for file systems which do not support wide-character name, and (3) even the committee members most interested in wide-character names are unsure that they are a good idea in the context of a portable library."
I interpret this to mean ...
That's the problem. The wording was intended to convey that there is considerable interest, but that there are unresolved technical issues. Someday someone will come forward with an actual written proposal. Instead of informal discussions, an actual vote will be taken. Then you will be able to say the committee is or is not in favor of the proposal. But that hasn't happened yet. --Beman
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. Jeff
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.
On Sun, 15 Feb 2004 22:48:53 -0500, Edward Diener wrote
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.
I see, I think misunderstood your point because I thought we were talking about wide char support for filesystem, sorry. I was really reacting to the "wall of resistance" analogy. If even there is such a thing with the std committee, the point was that it can't apply here at Boost since you and everyone else are free to go do the work and show how it can be done.... Also, I believe filesystem::path could and should be refactored to support wide strings on platforms that provide this capability. Obviously using this interface would limit portability, but the issue clearly needs to be explored. Sounds like Beman is working on some ideas. And I'm willing to wait as long as it takes because it isn't going to be easy and I don't have the motivation to go and try...
...snip....
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.
Agree.
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.
Agree. Jeff
At 09:49 AM 2/16/2004, Jeff Garland wrote:
... Also, I believe filesystem::path could and should be refactored to support wide strings on platforms that provide this capability. Obviously using this interface would limit portability...
My intent for filesystem::wpath (note the "w") is that it should work whenever possible on operating systems which use char as the external representation type. There would certainly be some limitations; the external encoding would have to be one that did not generate invalid names. For example, wpath on Linux would presumably use UTF-8 as the default external encoding, so that should work just fine. On Windows, the wpath internal and O/S external encoding are the same, so the same code would work on both Windows and Linux, and probably quite a few other O/S's too. --Beman
On Mon, 16 Feb 2004 12:38:47 -0500, Beman Dawes wrote
At 09:49 AM 2/16/2004, Jeff Garland wrote:
Also, I believe filesystem::path could and should be refactored to support wide strings on platforms that provide this capability. Obviously using >this interface would limit portability...
My intent for filesystem::wpath (note the "w") is that it should work whenever possible on operating systems which use char as the external representation type. There would certainly be some limitations; the external encoding would have to be one that did not generate invalid names.
For example, wpath on Linux would presumably use UTF-8 as the default external encoding, so that should work just fine. On Windows, the wpath internal and O/S external encoding are the same, so the same code would work on both Windows and Linux, and probably quite a few other O/S's too.
Sounds like a solid plan to me :-) Jeff
At 12:19 PM 2/15/2004, 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.
Do you have a reference for a good source of information about OS X handling of paths?
Presumably Linux still works with multi-byte characters.
Is there progres toward a wchar_t-aware path?
Yes. I now have the outline of a design for the internationalization of Boost.Filesystem paths. The C++ committee meets in Sydney, Australia, next month, and the LWG will be queried to see if they are interested in the standardization of an internationalized version of Boost.Filesystem based on that design. If so, I'll start work on a prototype.
Is there an existing strategy for storing my Unicode Windows/Mac paths as UTF-8 with the existing path?
No, you would have to do the conversion yourself. It would be nice if Boost had a std::locale codecvt implementation for UTF-8 conversions.
I notice the existing posix checks would fail horribly in this case. Is a UTF-8 checker in order?
It wouldn't hurt. Care to contribute one? --Beman
Beman Dawes <bdawes@acm.org> wrote:
At 12:19 PM 2/15/2004, Paul Miller wrote:
Presumably Linux still works with multi-byte characters.
Is there progres toward a wchar_t-aware path?
Yes. I now have the outline of a design for the internationalization of Boost.Filesystem paths.
Care to share? I'm curious how you handle some of the legacy Japanese encodings. Regards, Walter Landry wlandry@ucsd.edu
At 12:49 AM 2/16/2004, Walter Landry wrote:
Beman Dawes <bdawes@acm.org> wrote:
At 12:19 PM 2/15/2004, Paul Miller wrote:
Presumably Linux still works with multi-byte characters.
Is there progres toward a wchar_t-aware path?
Yes. I now have the outline of a design for the internationalization of
Boost.Filesystem paths.
Care to share? I'm curious how you handle some of the legacy Japanese encodings.
The framework looks something like this: There are internal representation types like char, wchar_t, or user-defined character types meeting std::string requirements. Those are handled by path, wpath, or a basic_path class template respectively. The encoding of char and wchar_t, of course, are defined by the compiler. The encodings of UDT's are defined by their implementations. There is one (usually, but with exceptions) external representation type. Each representation type may support multiple external path name encodings, including user defined encodings, subject to the operating system's encoding limitations. There will be a locale based (ie codecvt) mechanism for converting between the internal representation type and encoding, and the external representation type and encoding. The mechanisms for default and explicit locale operations will presumably be modeled on those of I/O streams. So handling the legacy Japanese encodings works like this: The programmer selects an internal type and encoding that can represent those external types and encodings. Perhaps wchar_t, but perhaps some UDT. The external type and encoding is presumably the operating system's default. The default locale mechanism will provide the codecvt facet to handle the conversions. So on a Japanese O/S, the external representation may be one of the legacy encodings, and if so the correct conversions will take place. Does that make sense? --Beman
Beman Dawes <bdawes@acm.org> wrote:
Does that make sense?
Perfect sense. I was a bit concerned that you were going to do something like convert everything to UTF-8 or treat everything as a stream of bytes. It sounds like you're foisting most of the responsibilities onto the programmer, which is fine with me. Regards, Walter Landry wlandry@ucsd.edu
At 01:20 PM 2/17/2004, Walter Landry wrote:
Beman Dawes <bdawes@acm.org> wrote:
Does that make sense?
Perfect sense. I was a bit concerned that you were going to do something like convert everything to UTF-8 or treat everything as a stream of bytes.
No, that was never a consideration. It would give only an illusion of solving the problem.
It sounds like you're foisting most of the responsibilities onto the programmer, which is fine with me.
I think of it as defaulting to something that is sensible for the operating system, but allowing the programmer to assume full responsibility if desired. --Beman
On Windows and OS X, you can work with paths in Unicode.
Do you have a reference for a good source of information about OS X handling of paths?
Here is a good tech-note on the "new way" vs. the "old way": <http://developer.apple.com/technotes/tn2002/tn2078.html> You can get to a Unicode path (encoded as UTF-8) from an FSRef through FSRefMakePath, or through CFURLs which seesm to be the preferred way of working with any kind of locator (file-based or not) on OS X.
Is there progres toward a wchar_t-aware path?
Yes. I now have the outline of a design for the internationalization of Boost.Filesystem paths. The C++ committee meets in Sydney, Australia, next month, and the LWG will be queried to see if they are interested in the standardization of an internationalized version of Boost.Filesystem based on that design. If so, I'll start work on a prototype.
I'd love to see it, and help in any way I can. IMO, filesystem::path is somewhat useless for I18N-aware applications. Linux might be the center of the universe to some, but I18N is extremely important on Windows and Mac, and they have both adopted Unicode. But, I think it could be made usable simply by supporting wchar_t strings. I am happy with having the onus of dealing with the long paths themselves in file operations or UI on my end - I don't need to wait for long path support in the C++ library, since I can implement the custom open myself.
I notice the existing posix checks would fail horribly in this case. Is a UTF-8 checker in order?
It wouldn't hurt. Care to contribute one?
I could probably be talked into it. On the other hand, it path supported wchar_t strings, it would be much more straightforward to deal directly with wchar_ts.
participants (3)
-
Beman Dawes -
David Abrahams -
Edward Diener -
Jeff Garland -
Paul Miller -
Peter Dimov -
Victor A. Wagner, Jr. -
Walter Landry