Hi, I am sorry for the length of the e-mail, I hope I make myself clear better than last time.
[mailto:boost-bounces@lists.boost.org] On Behalf Of Bennett, Patrick
On Behalf Of Ferdinand Prantl
I have nothing against usage of UTF-8 if it suits the scenario well. I just say that it is not an encoding for all purposes. It is a multibyte one and so extremely inefficient for getting size, searching, etc.
[Bennett, Patrick] I fail to see how this is the case. Right now, today, filesystem supports *only* ascii. If you
IMHO it is not true. boost::filesystem does neither recoding nor modification to the strings passed into its methods. It calls underlying OS functions, the XxxA methods on Windows and the POSIX functions on UN*Xes. These work with the current locale on UN*Xes and in the current ANSI codepage on Windows. They accept all characters valied in the current codepage. If you change it, you may see the filenames crippled, because the characters can be mapped differently, but that's it, it's not problem of boost::filesystem. This the current boost::filesystem does not solve and lets it on the programmer, to convert the filenames, if needed. You can use UTF-8 even today on non-Windows platforms. Unfortunately, there is no setting on Windows to enforce a UTF-8 codepage, like on UN*Xes. You set the regional settings and the codepage is assigned automatically. So the XxxA functions continue use the ANSI encoding. Well, the speed of searching in filenames can be discutable... But I like to use only one string type for everything in my application model and convert only on rare places, where a contact with OS is necessary. I like to use wstring only.
If you continued to use ASCII, nothing would change.
Yes, if I used ASCII but I use all characters from the current locale. I write localized application, including names of files. Then simply throw UTF-8 in would break it.
There is zero speed penalty for calculating the # of *bytes* in an utf-8 string. If you want to determine the # of characters, then there is, but then only if you're actually working on a Unicode string. There is no getting around this for an international application, no matter what encoding is used.
It is not predictable, if there are some non-ASCII characters in a string or not. Use a different, more suitable Unicode encoding for it. If you have to declare the complexity of your algorithms and the application is time critical, the multibyte (UTF) encodings are not used, but the fixed-byte (UCS) ones. UTF are recommended for transport because they do not waste space, UCS for runtime because they guarantee constant complexity of operations. But it is not a dogma, UTF encodings are not "forbidden" in runtime, it depends on requirements on an application. Windows (XxxW) and Java use UCS-2 for the Unicode character representation in their APIs, for example.
Why to prescribe it for all boost::filesystem users and force them to put recoding into their sources,
[Bennett, Patrick] Absolutely no recoding would be necessary for current users of boost::filesystem. boost::filesystem has no support for unicode today, so why would they have to recode anything?
As I said, absolutely no recoding is necessary now, if you use boost::filesystem with the strings in a native codepage. For example East Europe or Cyrillic. Everything will work well because you deliver your application localized in these countries. If you start accepting only UTF-8, such application would be broken. The application, which does not use Unicode (on Windows it does not have to and it can run on Japanese Windows good though), would have to perform recoding from the local codepage, in which it works, into UTF-8, which boost::filesystem would accept. And I did not mention, that Windows9x do not implement all XxxW methods (aditional library must be used to compile an application) and the recoding methods on Windows95 do not have support for UTF-8 as a codepage as Windows 98/NT have. It would mean a different solution for Windows9x withinn boost::filesystem.
UTF-8 is not identical with the complete iso-8859-1 (latin1) codepage. Some code could be broken by accepting UTF-8 in the new version.
[Bennett, Patrick] Hmmm, good point, but... would it break for any of the characters that are valid characters for a path or filename on an 8859-1 system? No, not that I can think of.
Again, valid are all characters in the current codepage for XxxA methods and in the current locale for POSIX methods. Except for wildcards and path delimiters, of course. Then it is change of interface breaking all usage scenarios.
[Bennett, Patrick] If you can think of a good way of handling this that doesn't involve a mess of codepages, locales, and facets, then I'm all for it. Frankly I think C++'s 'built-in' internationalization support is a nightmare, but that's probably just me. My (intentional) limited exposure to them probably hasn't helped. It's hard to beat having a 'single' encoding like UTF-8 that can handle all defined characters. Unicode is definitely the way to go IMO.
Unicode is the ideal way, however, not all systems support it or are configured to use it. If you force its support in boost::filesystem, you would force Unicode to all applications using it, which do not do it now. Currently boost::filesystem does not force it, but allows it with the following setup: A local encoding on UNIX: no problem OS: configure for example cs_CZ environment boost::filesystem: use cs_CZ strings UTF-8 on UNIX: no problem OS: configure UTF-8 environment boost::filesystem: use UTF-8 strings A local encoding on Windows: no problem System: configure for example Czech environment boost::filesystem: use czech strings Windows has no predefined regional settings with UTF-8, but uses always an ANSI codepage. Unicode support is additional and preferred for NT. If you wanted UTF-8 on API boost::filesystem, you would have to: 1) either use XxxW methods in boost::filesystem and convert from UTF-8 to UCS-2 2) or recode the input UTF-8 strings into the local ANSI codepage within boost::filesystem to be able to use XxxA methods ad 1) it needs a recoding engine (built in Windows, for UTF-8 on 98/NT) ad 2) it will work for names from the current codepage only (UTF-8 recoding is from 98/NT)
My real issue with boost::filesystem is that as currently defined, it's unusable in an application that will be used around the world. My initial response to this whole thread was just to point out to David that there *are* issues preventing people from using the library. He didn't think there were any, so I was compelled to point out what one of the issues was for me at least.
Could you specify exactly what prevents you to use it? I can use boost::filesystem in czech and russian environments happily and for japanese it is the same as long as you stay within the local codepage. boost::filesystem is perfectly usable in any localized application, which instance runs in a single language environment. The application itself can be installed in any language environment, however. The only thing you have to keep in mind is, that the strings being accepted by boost::filesystem are in the current locale/ANSI codepage. The problem is somewhere else and does not concern only boost::filesystem but the whole locale support by OSes. Just to clarify: localized application is an application, which can run on a localized environment, has a localized interface and accepts all arguments (here: filenames) from the localized environment. This boost::filesystem fulfills this for any existing locale, including japanese, without recompiling (single binary, localized resources). Nowadays comes another requirement - sharing applications and its data throughout more locales (locale switching, data distribution) without loosing information (here: crippled characters in filenames). To make myself clear - to use more locales together in a single application, for example czech, russian and japanese together. Unfortunately, this is not possible to achieve using POSIX methods (libc, libstdc++/STL), because they use the current locale, which does not need to be defined to Unicode (UTF-8) but to any ANSI. AFAIK only Windows implement C/C++ runtime with native Unicode suport, using UCS-2. It is a question, if boost::filesystem should help it. Currently it behaves the same way, how POSIX and libc and libstdc++/STL: works in the current locale. I think, that ANSI-C comitee should have updated the library specification to contain wchar_t methods since a long time, btw... It could have a positive influence on std::streams (wchar_t* methods) and boost::filesystem as well. In such ideal worlds you would have no problems :-) You are right in these points: 1) you cannot write an application, which has characters from more codepages (locales) in a filename 2) if characters in two codepages are mapped differently, filenames would be incompatible, although the characters are valid in both encodings Currently you are not able to write applications for Windows, which require usage of Unicode API (XxxW functions) - the two poins above. It is not because boost::filesystem does not use UTF-8. It is because: ANSI-C does not use Unicode -> ANSI-C++ (STL) does not use Unicode -> boost::filesystem does not use Unicode. My opinion: the way to solve it is not to change encoding of std::string and char* parameters of the current boost::filesystem to UTF-8 but to follow the STL way - to introduce methods with std::wstring and wchar_t or better, templatize it with basic_string<CharType>. It is difficult because wchar_t is not in STL and libc, I know.
At the company where I work we're currently just pursuing our own wrappers for what filesystem provides. I originally tried using filesystem, but once I saw that it's handling of internationalization was absent, I had no choice but to dump it. I certainly have an interest in it being improved, and I could see looking at it again, but someone will have to spearhead that initiative. Considering that this hasn't really been brought up before tells me that people either aren't using the library, or simply don't care about internationalization (probably the latter). I, unfortunately, don't have that luxury.
I am from an Eastern European country and you bet we are concerned with internationalization. However, no change comes without a discussion and you are not alone using the library and your suggested change would make the others (at least me ;-) dificulties. If nobody has got the problem could also mean, that there is a usage style, which works. This I pointed out above. Besides, I don't have the luxury to support platforms with full support of XxxW methods and UTF-8 support in WideCharToMultibyte. That's why would like to extend boost::filesystem with the support of the current behavior (work in the current locale) but for Unicode applications perform recoding, which does not need to happen, if OS supports Unicode natively. That's why I pointed out the imbue principle used in std::streams for the similar case - application can work in Unicode (UCS-2 wchar_t) and content of the stream can be in any encoding (including UCS2 wchar_t for no recoding). Ferda
Cheers... Patrick Bennett