Boost logo

Boost :

From: dietmar_kuehl (dietmar_kuehl_at_[hidden])
Date: 2002-03-04 08:25:21

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.

> For POSIX however, assuming you go the ctype-narrow/widen approach,
> the main issue is of course which locale to request. I would say
> locale("") (ie the default "system" locale), but there probably
> to be a once-off method of overriding this.

I think the "C" locale is the right one to choose because the other
locale depends on user perferences. Hence, filenames written by my
russion collegue may be pretty unreadable to me, although I can read
Cyrillic letters - I just can't tell what Cyrillic characters are
those I see which are German ones.

> One thing that might be generically useful is UTF-8 <-> UTF-16 <->
> UTF-32 conversion. Not much use for filesystem support seeing as
> very few filesystems use these standards

Basically, this is what 'std::codecvt' is intended for and, although
useful for itself, not the scope of the conversion proposed by Jan.
Basically, what Jan proposes is what is done inside the standard
library eg. when formatting or parsing wide character strings
representing eg. numbers: Individual characters are
'std::ctype<cT>::narrow()'ed or 'std::ctype<cT>::widen()'ed. No real
code conversion, merely character mapping.

<mailto:dietmar_kuehl_at_[hidden]> <>
Phaidros eaSE - Easy Software Engineering: <>

Boost list run by bdawes at, gregod at, cpdaniel at, john at