From: Samuel Krempp (krempp_at_[hidden])
Date: 2003-09-15 13:05:17
On Sun, 2003-09-14 at 23:04, Stefan Seefeld wrote:
> You really need a unicode library to deal with these issues. A unicode-enabled
> path manipulation library would have to depend on it. Of course, one could
> provide a templates based interface, where you plug in the unicode support
> in terms of string and trait type parameters.
hmmm, I wonder if you really need a unicode library.
UTF-8 being designed as a superset of ASCII so that most code could
carry UTF-8 strings transparently, a path manipulation could find '/' or
'\' and other filesystem special chars in a UTF-8 string, do its thing,
and obtain a valid UTF-8 string.
But then, what happens with the windows API if a fstream is constructed
with the UTF-8 encoding of an existing unicode pathname ?
Either the windows API has a default encoding for simple char strings
set to iso-8859-x s and will misunderstand the string,
either it defaults to UTF-8 and it should work fine.
I don't know windows enough to tell which it is.
Maybe the user can configure that somewhere.
if so the boost::filesystem could be used to work with unicode paths, if
the user encodes the unicode path to UTF-8.
(and encoding to UTF-8 should only require having a UTF-8 locale
available, not necessarily installing a unicode library.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk