Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-11-11 20:36:08

Beman Dawes wrote:
> At 12:41 PM 11/11/2004, Peter Dimov wrote:
>> In particular, the user cannot define the conversions
>> between the different path types, because they are implementation
> defined.
> The default conversion is implementation defined, but users can supply
> their own conversion. One use case I have in mind is a character
> based O/S which uses some MBCS encoding of paths that isn't UTF-8,
> but the user wishes to burn a CD with UTF-8 encoding. The user should be
> able to
> provide such a conversion function, overriding the implementation
> defined default.

I see no need for custom conversions in this case. The user can just supply
the appropriate narrow UTF-8 path directly. I also don't see where the
implementation-defined default enters the picture, as the translation is
between char and char.

> Another case of particular interest is Windows where the external
> type is 2 bytes and the user chooses path, which is char based, as
> the internal type for directory iteration. What happens when an
> directory entry uses the high-order byte? The default conversion
> supplied by the Windows API is lossy; the high order byte is simply
> discarded.

The conversion depends on the current codepage, AFAIK. The high byte is only
discarded if you're using windows-1251 (a superset of ISO-8859-1). A custom
conversion simply cannot work portably.

Besides, if the user knows that he'll need a custom conversion, it's much,
much easier to just use wpath.

Anything besides path/wpath is even less useful than basic_string that isn't
string or wstring, amazing as this may be, and we all know how popular
basic_string is.

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