Re: [boost] [locale] Formal review of Boost.Locale library EXTENDED

Subject: Re: [boost] [locale] Formal review of Boost.Locale library EXTENDED
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-04-20 10:06:20

> I don't  understand what are you trying to solve by that so called  solutions.
> 
> Solution A does not work at all.
> There is no guarantee  ordinary string literal is UTF-8 encoded.(and it
> always isn't in  MSVC).
> 

You are right, I missed it.

After digging a little I've now surprised how
broken MSVC's behavior is $%&#%$^&#%^#%^#$%^#$%^#$%^

Seriously...

- Without BOM I can't get L"日本語" as UTF-16 to work when
  the sources are UTF-8 (however char * is valid utf-8),

  It works only when the sources are in the current
  locale's encoding that actually may vary from
  PC to PC so it is totally unreliable.

- With BOM while I get L"日本語" as UTF-16...
  I can't get "日本語" as UTF-8 at all it still
  formats them in current locale, which is 
  unreliable as well.

But you know what? It just convinces me
even more that ASCII strings should be
used as keys with all this nonsense 
with MSVC compiler.

> 
> Solution B... What are you doing?
> Isn't  wxtranslate(WTR("日本語")) ended up pointer to const wchar_t that
> refers to  L"日本語" ?
> It does nothing except it works as a macro which add L encoding  prefix.
> If so, I'd rather write L"日本語" directly.
> 

I see why the second case does not work unless your
"ids" are in Shift-JIS.

Any way, the things you say even increases the total
mess exists in current charset encoding.

From all compilers I used (MSVC, GCC, Intel, SunCC, OpenVMS's HP)
all but MSVC handle UTF-8/wide/narrow characters properly.

I'm sorry I was thinking about it too good things.

This way or other it convinces me that you 
can relay only on ASCII.

Artyom