Vladimir Prus
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.
It doesn't have to be. There can be a library object with explicit instantiations of the wide and narrow classes. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com