|
Boost : |
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://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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk