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 $%&#%$^&#%^#%^#$%^#$%^#$%^
- 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk