On Sat, Feb 26, 2011 at 1:31 AM, Jeff Flinn <TriumphSprint2000@hotmail.com>wrote:
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 appropriate.
Do others have thoughts on this issue? Are the windows wide api usage part of boost guidelines? Should they be?
Thanks, Jeff
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
This is actually the reason I avoided interprocess::mapped_file in one of my own projects some time ago. Use of the wide APIs under Windows is important if you are aiming for I18n.