Subject: [boost] [filesystem v3] [iostreams] [interprocess] no windows access to memory mapped file
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2011-02-25 09:31:51
Filesystem V3 does a great job of handling unicode/utf8 paths in a
windows/posix independent manner.
boost::interprocess::file_mapping's constructor takes a raw const char*
and explicitly calls CreateFileA to get a handle to a memory mapped file
disallowing access to paths with non-ascii characters.
boost::iostreams::mapped_file has a 7 month old ticket #4485 outlining
the problems using it with filesystem V3. There is some path width
switching logic that dispatches to CreateFileA or CreateFileW when the
mapped_file is constructed with a filesystem V2 wpath. I tried faking
things out by creating a wpath class in the filesystem namespace, but
gave up and created a mapped file class for windows that uses
filesystem::path and CreateFileW.
I posted the issue with interprocess and Ion was of the opinion that
this shorcoming needs to be addressed. I'm not sure if Steven is
maintaining iostreams, or if he has given thought to how to address the
iostreams implementation. My opinion is that boost libraries using paths
in their interfaces should be using filesystem v3 paths. Beman, I think,
suggested in the recent utf8 thread that boost libraries should use the
wide version of the windows api passing path.wstring().c_str() where
Do others have thoughts on this issue? Are the windows wide api usage
part of boost guidelines? Should they be?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk