C++ Logo

SG16

Advanced search

Subject: Re: [SG16-Unicode] code_unit_sequence and code_point_sequence
From: Tom Honermann (tom_at_[hidden])
Date: 2018-06-19 13:44:33


On 06/19/2018 02:16 PM, Lyberta wrote:
>
>> 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.

Because that enables wrapping network and file based I/O without
requiring additional storage or conversions.  These are real use cases. 
Perhaps you just haven't had a need for them?

I wonder if there is some disconnect between what text_view provides and
what you think it provides.  It would be helpful if you were to provide
some example code that we could use to clarify discussion; something
that would allow side-by-side comparisons of various interfaces.

>
>> 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.

Whether BE/LE variants are provided and whether their interfaces have
encoding tags in their signatures are orthogonal concerns.  I still
don't understand your distaste for the BE/LE variants or what harm is
caused by providing them.

>
>> 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.

That doesn't isolate programmers that use the standard library from
being impacted.

Tom.


SG16 list run by herb.sutter at gmail.com