Delfin Rillustration> So what I ask is a library that works everywhere, just like you say.
I understand your point about POSIX file systems but since the library is compiled for Windows _or_ for POSIX systems I think it would be possible to compile for single char strings or double byte strings (UTF16). Windows systems solve this problem with the concept of TCHAR, a type that is defined as a char or wchar_t depending on a preprocessor definition. Then, boost::fylesystem::path could accept std::basic_string<TCHAR> instead of std::basic_string<char>. That would solve the problem and everybody would be happy ;)
I'm very much opposed to the idea of having templated classes for unicode support. Let me explain. Suppose I write a library which does something with strings, paths, whatever in the interface. I have these choices: 1. Make the library interface templated. 2. Use narrow classes: e.g. string 3. Use wide classes: e.g. wstring 4. Have some class which works with ascii and unicode. The first approach is bad for code size reasons. If the library does substantial work (e.g. HTTP library), it better be dynamic library, so that applications don't have include all the code. Of course, you might want static linking, but dynamic linking should be possible too. The second approach is what's commonly done. As the result, unicode is not very supported in the standard C++. The third approach looks reasonable. However, Mr. Random Library Writer might think: "I don't have a need for unicode now, so wstring is overhead". So he might discard this approach and use std::string. Even if wstring is used, there are some issues. E.g. std::wstring does not have a constructor taking either char* or std:string, or if you ever get ascii string, you're in trouble. The last solution is what looks most reasonable to me. It would be nice to have unicode string which can be created from ascii or unicode, converted back to either representation, and manipulated without regard to encoding. For fs::path it would be that unicode will be just supported. The templated solution will bring us back to the above choice. And if you have a library which has boost::filesystem::basic_path<char> in the interface, it does not matter if your whole application uses basic_path<charT> -- you'd need conversions somewhere, so why don't have single fs::path which can do all conversions. Just an illustraction: class path { path(const std::string& s); // The 's' is in the local 8-bit encoding path(const std::wstring& s); // The 's' in in unicode template<class charT> std::basic_string<charT> native_file_path(); // other operations, independed of charT }; - Volodya