$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [filesystem v3] [iostreams] [interprocess] no windows access to memory mapped file
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2011-02-28 12:04:09
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.
>
>> Do others have thoughts on this issue? Are the windows wide api usage
>> part of boost guidelines? Should they be?
>
> AFAIK, we have no guidelines,
I was hoping to get more feedback from others on this topic. Wouldn't it
be beneficial at least to address the file open issue?
Jeff