C++ Logo

SG16

Advanced search

Subject: Re: [SG16-Unicode] code_unit_sequence and code_point_sequence
From: Lyberta (lyberta_at_[hidden])
Date: 2018-06-19 13:16:00


Tom Honermann:
> On 06/19/2018 04:11 AM, Lyberta wrote:
> UTF-16 and UTF-32 are convenient for views over u"text" and U"text"
> respectively.  And the BE/LE variants are useful as views over (byte
> oriented) network and file I/O (without having to first convert from
> encoding scheme to encoding form).

Yes, but I think those views should not share the same class template.

> Following the thread further, it seems you would like to have a simple
> codec for translating BE/LE data (e.g., to load BE/LE byte oriented data
> into native endian larger-than-byte types).  That sounds reasonable, but
> I don't see why it should be part of text interfaces.

I agree and I don't see why BE/LE variants of encodings should be
parameters to text_view. Maybe we should defer endianness and BOM issues
for later.

> Text_view precedes the introduction of std::endian.  Regardless, I don't
> think I would want std::endian to be part of the encoding signatures;

Exactly. Drop BE/LE variants.

> Note that endian::native may or may not equal either
> of endian::big or endian::little, so writing class template
> specializations would get ugly.

Since we are aiming for a standard library, it is assumed that
implementers know the value of std::endian::native.




SG16 list run by herb.sutter at gmail.com