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