C++ Logo

sg16

Advanced search

Re: [SG16] Agenda for the 2021-04-28 SG16 telecon

From: Victor Zverovich <victor.zverovich_at_[hidden]>
Date: Tue, 27 Apr 2021 07:52:00 -0700
Dear Unicoders,

Thanks, Tom, for putting together a detailed list of options. Just want to
add that print is a completely wrong abstraction level to try to address
this (we should address it but it has little to do with P2093). The root
cause is a mismatch between literal and locale encoding and it should be
addressed on the formatting level in cases where a locale is used. Here's
an example from another thread that illustrates this:

  std::cout << std::format("时间 {:%r}\n",
std::chrono::system_clock::now().time_since_epoch());

I think this belongs to a separate small (but important) paper unless the
resolution is so trivial that it can be a drive-by fix in P2093.

One more option is to give a runtime error when trying to use (via 'L' or
other means) a locale with the encoding incompatible with the literal
encoding. I'd either go with that or do transcoding. Dropping UTF-8
handling is the least desirable option in my opinion and will basically
render the feature useless for me as a user.

I mostly agree with Corentin except that '%r' can be considered as an
explicit locale opt-in similar to 'L'.

Cheers,
Victor

On Tue, Apr 27, 2021 at 4:11 AM Corentin Jabot via SG16 <
sg16_at_[hidden]> wrote:

>
>
> On Tue, Apr 27, 2021 at 12:57 PM Jean-Marc Bourguet via SG16 <
> sg16_at_[hidden]> wrote:
>
>> I'm probably too much a Unix guy, but having
>>
>> prog
>>
>> and
>>
>> prog | more
>>
>> or
>>
>> prog > file; cat file
>>
>> displaying different things is not something that meets my expectations.
>> The difference in buffering behaviour is already hard enough to explain.
>> Piping to more is far too common for it behaving differently than direct
>> output.
>>
>> Yours,
>>
> Either way you are printing out the same content.
> Except in one case it is _rendered_ correctly and in the other it might
> not.
> This will also not affect linux, it is addressing a very windows-specific
> problem for which the encoding the console assumes by default is not the
> execution encoding.
> This is explained in more details in Victor's paper
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2093r5.html#unicode
>
>
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>

Received on 2021-04-27 09:52:13