boost.filesysten v3 breaks boost:::iostream::mapped_file

[ttan@…]

boost:::iostream::mapped_file has been design so that when passing file path to the constructor or open(), it only accepts 3 types: std::string, boost::filesystem::path, boost::filesystem::wpath.

due to the late update to boost::filesystem v3, boost::filesystem::path is no longer templated, and wpath is gone. and as Windows uses UTF16, when a path is converted from utf16 to a certain ANSI/OEM code page(CP), causes information loss, for example, "Apress ©" in unicode would be converted to "Apress ?" in CP936, where code point 0x00a9(©) is lost, though it's a legal character in file name.

it amounts to that support for std::wstring in boost:::iostream::mapped_file is gone.

a patch is needed to remove the dependence on boost.filesystem v2, and revert to the support of std::wstring, which can be get from path.wstring() in boost::filesystem v3.

[Jeff Flinn <jflinn@…>]

workaround to adapt filesystem vs path for use with file_descriptor and mapped_file

[Jeff Flinn <jflinn@…>]

The previously attached filesystem_v3_path_adapter.hpp file allows boost filesystem V3 path to be used with file_descriptor* and mapped_file* classes. I've tested this on Windows MSVC8 & Mac XCode 3.1.2/gcc 4.0.1 with utf8 paths. On windows it makes the wide CreateFileW interface accessible for opening unicode path'd files. Example usage:

#include <boost/iostreams/device/mapped_file.hpp> #include <boost/iostreams/filesystem_v3_path_adapter.hpp>

...

boost::filesystem::path p(...);

namespace io = boost::iostreams;

io::mapped_file_source mf_src(io::filesystem_v3_path_adapter(p));

...

[zhuo.qiang@…]

another way adding boost::filesystem v3 support

[zhuo.qiang@…]

Another way for adding Filesystem v3 support is to make boost::iostreams::detail::path be constructable from boost::filesystem3::path

See the attachment for the ​patch.

[Daniel James]

(In [72382]) Iostreams: Support filesystem3 paths. Refs #4485.

Based on Zhuo Qiang's patch with added tests and support for operator=.

I also used codecvt_type to detect filesystem3::path instead of string_type. Using string_type made filesystem2::path ambiguous because it has both string_type and external_string_type members.

The member types are a bit arbitrary, but a more precise distinction would probably also be more expensive.

[anonymous]

This was fixed in [72491] and [72774], and released in 1.47.0.