Re: [boost] [locale] Review results for Boost.Locale library

Subject: Re: [boost] [locale] Review results for Boost.Locale library
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2011-04-27 18:20:31

On 04/27/2011 03:05 PM, Marsh Ray wrote:
> On 04/27/2011 02:23 PM, Jeremy Maitin-Shepard wrote:
>> On 04/27/2011 11:46 AM, Marsh Ray wrote:
>> > [comments about ASCII requirement]
>>
>> A suggestion was made at one point that an ASCII transliteration of
>> Japanese would be a possible solution, and I think most of us can agreed
>> that should be rejected immediately as a non-viable solution.
>>
>> However, forcing MSVC users to use one of the Windows "ANSI" encodings,
>> such as windows-936, wouldn't be nearly such an impediment.
>
> I've worked at places where I couldn't use certain Boost libraries
> because I couldn't change the necessary compiler setting to work around
> a well-documented bug in MSVC). At this place they also questioned
> whitespace changes which were not even affecting visible formatting.
> Thankfully I don't work there any more.
>
> I don't know how much of a change it is for a software developer in
> Japan to convince his team to change their source file encoding so they
> can use some library. It's probably non-trivial.
>
> What I do know, however, is that the set of users who are candidates for
> ending up as happy users of a library is always much greater when the
> library developers don't think they can "force" users to adopt specific
> compiler settings or agree to other nonstandard constraints.

I'm not talking about the encoding of the source, but about whether L"" 
literals are used or not.  (If "narrow" literals are used in MSVC, they 
will be in the execution character set, which is never UTF-8 and in the 
case of Japanese users might likely be windows-936.)  Regardless, 
though, it seems that Artyom has proposed to support whcar_t and (once 
supported by the compiler) char16_t and char32_t literals, with the only 
caveat that the literal type must match the output type (which is kind 
of an unnecessary limitation but simplifies the interface and in 
practice is unlikely to be a problem).