Re: [boost] Silly Boost.Locale default narrowstringencodinginWindows

Subject: Re: [boost] Silly Boost.Locale default narrowstringencodinginWindows
From: Alf P. Steinbach (alf.p.steinbach+usenet_at_[hidden])
Date: 2011-10-28 11:59:01

On 28.10.2011 16:10, Peter Dimov wrote:
> Alf P. Steinbach wrote:
>
>> This difference in conversion & wrapping effort was the reason that I
>> used both the standard library and the OS API in my original example.
>
> Using the OS API makes your program non-portable, so it's not clear what
> the example is supposed to demonstrate.

It demonstrates what I said.

That no data conversion is needed for calling API functions.

Your argument would to some extent make sense if you are assuming that 
the two worlds of OS-specific and portable code will always be 
completely separate, never touching  --  but I find that unrealistic.

> You may as well stick to
> wchar_t; Windows 95 is ancient history and the whole wrapping effort is
> completely unnecessary.

Sorry, that's meaningless to me.

It sounds like free association.

> The portable version of your example would be something along the lines of:
>
> #include "message_box.hpp"
> #include <stdio.h>
>
> int main()
> {
> char buffer[ 80 ];
> sprintf( buffer, "The answer is %d!", 6*7 );
>
> message_box( buffer, "Title", mb_icon_information );
> }
>
> where message_box has implementations for the various OSes the program
> supports. On Windows, it will utf8_decode its arguments and call
> MessageBoxW.

There is no need to add inefficient translation to the mix.

> A localizable version would not embed readable texts:
>
> #include "message_box.hpp"
> #include "get_text.hpp"
> #include <stdio.h>
>
> int main()
> {
> char buffer[ 80 ]; // ignore buffer overflow for now
> sprintf( buffer, get_text( "the_answer_is" ).c_str(), 6*7 );
>
> message_box( buffer, get_text( "title" ), mb_icon_information );
> }
>
> Now get_text may return something in Chinese (UTF-8 encoded) and it will
> all work.

This may conceivably make sense at some enterprise level.

> It's also possible to use wchar_t for human-readable text throughout the
> code base - this provides a layer of type safety. You'll have to replace
> sprintf with swprintf then. Paths, however, are better kept as char[].

Sorry, again I fail to discern the underlying thoughts.

It sounds like free association.

Cheers & sorry, no comprende,

- Alf