C++ Logo

SG16

Advanced search

Subject: Re: Is the concept of basic execution character sets useful?
From: Hubert Tong (hubert.reinterpretcast_at_[hidden])
Date: 2021-02-03 16:24:27


On Wed, Feb 3, 2021 at 5:13 PM Corentin via SG16 <sg16_at_[hidden]>
wrote:

>
>
> On Wed, Feb 3, 2021 at 11:04 PM Jens Maurer <Jens.Maurer_at_[hidden]> wrote:
>
>> On 03/02/2021 00.09, Corentin wrote:
>> >
>> > On Tue, Feb 2, 2021 at 11:57 PM Victor Zverovich <
>> victor.zverovich_at_[hidden] <mailto:victor.zverovich_at_[hidden]>> wrote:
>> >
>> > > For the core language, I think we should
>> > > simply replace "execution character set" with "literal encoding"
>> (narrow and wide),
>> > > because we never actually care about character sets, just about
>> encoding
>> >
>> > I would be very much in favor of this change. "Literal encoding" is
>> exactly what this is and "execution character set" is just confusing. I
>> also agree that it shouldn't be tied to locales in any way.
>> >
>> >
>> > I'd love feedback on the draft I posted earlier in this thread which
>> does that, whenever you have time before the next deadline :)
>> > A slightly more recent draft is here
>> https://isocpp.org/files/papers/D2297R0.pdf <
>> https://isocpp.org/files/papers/D2297R0.pdf>
>>
>> The change for wchar_t in [basic.fundamental] says that wchar_t
>> can now use UTF-16 (i.e. one or two code units per code point)
>> Previously, wchar_t needed to be >21 bits for full Unicode support,
>> otherwise "distinct codes for all members of [Unicode]" is not
>> satisfied.
>>
>> That seems a drastic change; I'm not sure which parts of the
>> iostreams library depend on wchar_t not using multiple code units
>> per code point.
>>
>> Also, it warrants an Annex C entry.
>>
>
> See earlier conversation in the thread, Hubert suggested that we could fix
> the core wording without necessarily fix the library (which is a whole
> different ball game, to the extent it might not be possible)
>
I didn't mean to say that accepting UTF-16 for wchar_t is something we
should "just fix" at this time. My question about the availability of
appropriate C library functions was meant to indicate that we need to work
with the C committee on this.

> wchar_t is not conforming on windows (their implementation uses 16 bits),
> which seems problematic as they are the primary users of wchar_t)
>
> I agree about the Annex C entry
>
>
>>
>> Jens
>>
>> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>



SG16 list run by sg16-owner@lists.isocpp.org