[Boost-users] wide-char version of boost::mapped_file?

Subject: [Boost-users] wide-char version of boost::mapped_file?
From: Tan, Tom (Shanghai) (TTan_at_[hidden])
Date: 2009-05-25 23:55:21

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.