By borrowing code from boost::filesystem V3, I re-implemented the to_string function like this: std::string to_string(const wstring& ws) { const size_t BUFFER_SIZE = (ws.size() << 1) + 1; shared_array<char> p_mcb(new char[BUFFER_SIZE]); int count = ::WideCharToMultiByte( AreFileApisANSI() ? CP_THREAD_ACP : CP_OEMCP, WC_NO_BEST_FIT_CHARS, ws.c_str(), ws.size(), p_mcb.get(), BUFFER_SIZE, 0, 0 ); return (-1 == count) ? std::string() : std::string(p_mcb.get(), count ); } This seems to have solved the conversion problem. Is it possible to add an overloaded constructor based on this code to take std::wstring or just take a boost::path when V3 comes out.? It would ease the usage a lot in my opinion. -----Original Message----- From: Tan, Tom (Shanghai) Sent: 2009-05-26 11:55 To: 'boost-users@lists.boost.org' Subject: wide-char version of boost::mapped_file? I am trying to use boost::mapped_file in the iostream library. While I like the interface. The fact that it only supports the ANSI version of windows API, thus dictating an ANSI version of file path, really drives me crazy. In my code I use std::wstring everywhere. Because boost::mapped_file asked for a std::string to construct like this: explicit mapped_file( const std::string& path, std::ios_base::openmode mode = std::ios_base | std::ios_base, size_type length = max_length, boost::intmax_t offset = 0 ); I wrote a small routine to convert it like this: std::string to_string(const wstring& ws) { const size_t BUFFER_SIZE = (ws.size() << 1) + 1; shared_array<char> p_mcb(new char[BUFFER_SIZE]); setlocale( LC_ALL, ".2052"); size_t count = wcstombs(p_mcb.get(), ws.c_str(), BUFFER_SIZE ); return (-1 == count) ? std::string() : std::string(p_mcb.get()); } It does not really work well when I have Enlish and Chinese characters mixed together in the path, while it does for pure Chinese paths. So I traced down to the source code to find out why a std::string instead of basic_string<Char> is needed, anyway, it's just a path, and has nothing to do with mapping it does. There seems to be no clue except for the ANSI version of Win32 APIs, which actually have wide-char versions. Did I missing any design requirement that force it to be like what it is today? Another issue is, it throws exception from inside the constructor when it tries to map a zero-length file. IMHO, it's not good to throw for a legal file, be its length zero, and not good to throw from the constructor either.