C++ Logo


Advanced search

Subject: Re: [isocpp-core] New draft revision: D2029R2 (Proposed resolution for core issues 411, 1656, and 2333; numeric and universal character escapes in character and string literals)
From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2020-07-03 02:11:55

On 02/07/2020 18.43, Tom Honermann via SG16 wrote:
> On 7/2/20 3:15 AM, Corentin via Core wrote:

>> literal encoding is a less ambiguous term either way.
>> We need a terminology such that we can distinguish the encoding of literals from that of runtime strings, literal (associated) encoding achieves that.
> Ah, I think we may be crossing hairs here.  I agree that we should have an abstract name that indicates the encoding used for literals.  We lack a term for that today (which is why the paper uses the phrase "encoding of the execution character set").  But that is different from what is intended by "associated character encoding"; this is intended to name an encoding (possibly indirectly, hence "encoding of the ...") that might be registered with IANA <https://www.iana.org/assignments/character-sets/character-sets.xhtml> (where the term "character set" is used to mean "character encoding", but the former is used for legacy reasons).

You lost me there.

What does IANA's list of character sets/encodings have to do with
how a compiler chooses to encode C++ literals?

Maybe the compiler has invented an encoding of its own, just
for the fun of it.

If you intend some stronger relationship to IANA here, this
needs to be a lot of explicit.


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