Re: [boost] [filesystem v3] [iostreams] [interprocess] no windows access to memory mapped file

Subject: Re: [boost] [filesystem v3] [iostreams] [interprocess] no windows access to memory mapped file
From: Ian Emmons (iemmons_at_[hidden])
Date: 2011-02-28 14:29:03

On Feb 28, 2011, at 4:52 AM, Ion Gaztañaga wrote:
> El 25/02/2011 15:31, Jeff Flinn escribió:
>> 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.
> 
> I wouldn't like to make Interprocess dependant on Filesystem just to handle paths, and the problem is not just related to mapped file, since some other Interprocess elements might require also wide string interface (like shared memory). So I'm afraid we need some kind of policy (and common code) to handle system calls with wide/utf-8 interfaces. This might require some heavy refactoring in Interprocess internals as there are some OS abstractions (file handling, unlink(), etc.) to simplify code and maintenance with narrow char interfaces.

You say you don't want Interprocess dependant on Filesystem, but you also say Boost needs common code to handle system calls with wide/utf-8 interfaces.  To me these are inconsistent statements.  To me, Filesystem _is_ the common code (at least for paths, which is the majority of cases).