$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-04 20:20:19
At 08:25 AM 3/4/2002, dietmar_kuehl wrote:
 >Hi,
 >dylan_nicholson wrote:
 >> However you can't assume that will do the correct mapping.
 >
 >It isn't expected to: The whole point is to support a wide to narrow
 >conversion (or vice versa) for characte representable with the narrow
 >character set. It is not intended to simulate wide character file
 >names on platforms where they are not supported. The intention is to
 >support code using wide character strings to represent the filenames
 >although the filenames are still restricted to contain only
 >characters representable with the narrow character set.
Ah! That hadn't been clear.  I've added the question and your reply to the 
FAQ I'm building up.
Here are related questions:
Why should the file system library supply specializations for any 
characters types beyond those actually supported by file system names on 
the platform?
Why shouldn't a separate conversion library (as proposed by Jan, using your 
code) be used if someone wants to convert between a character type 
supported by the file system and a character type not supported by the file 
system?
In other words, an NT file system implementation would support both char 
and wchar_t, but POSIX (which if I understand correctly only supports char) 
would only supply specializations for char.  If conversion was desired, the 
separate conversion library could be used.  Wouldn't this answer the 
concern of Asian nations that we not mandate a particular filename 
conversion scheme?
Thanks,
--Beman