Subject: Re: [boost] [filesystem v3] [iostreams] [interprocess] no windows access to memory mapped file
From: Joshua Boyce (raptorfactor_at_[hidden])
Date: 2011-02-28 03:20:46
On Sat, Feb 26, 2011 at 1:31 AM, Jeff Flinn
<TriumphSprint2000_at_[hidden]>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://listarchives.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.