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: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2011-02-28 17:00:55

El 28/02/2011 20:29, Ian Emmons escribió:
> 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).

It is not the common code for handling string conversions at OS level. 
The OS has many resources not related with paths: named semaphores, 
shared memory, named mutex, etc.. We need to handle all of them, 
filesystem handles strings for what its name says: filesystem. And 
filesystem uses locales associated with paths for that job, I don't know 
if that's the correct way to do it in Interprocess. Maybe it is, maybe 
it is not.

At least for Interprocess, the easiest way is to offer wide string 
interface for OS that supports them (like windows). I don't know if 
names in narrow chars should be treated as utf-8, if all resource names 
should be treated as paths...Filesystem name encoding could be a valid 
example for other libraries, and it would be nice if such code could be 
taken out to be used for other named resources that also need such 
conversions, out of other filesystem resources like copying a file, etc.

But anyway, I will study filesytem v3 to see if it's the answer. But 
sadly this has low priority in my to-do list.

Best,

Ion