Date: Fri, 26 Feb 2021 12:43:36 -0500
On 26/02/2021 10.48, David Bakin via Std-Discussion wrote:
> I believe it would be more aligned with the C++ philosophy that this newly
> standardized feature be as fundamental as possible - as close to the metal
> as possible - and thus be a byte-swap proposal and not a
> "make-it-this-endian" proposal. "make-it-this-endian" is built from two
> lower level primitives: is_little_endian? and byteswap. To standardize
> "make-it-this-endian" would leave the use cases needing simply byteswap out
> in the non-standardized cold. And yet it would be easy to _build_
> "make-it-this-endian" on top of is_little_endian? (now called `std::endian`
> in C++20) and byteswap.
Yes, but given that most uses *are* "make it this endian", it would be
silly to not have that as well. It's probably best to offer both.
> I believe it would be more aligned with the C++ philosophy that this newly
> standardized feature be as fundamental as possible - as close to the metal
> as possible - and thus be a byte-swap proposal and not a
> "make-it-this-endian" proposal. "make-it-this-endian" is built from two
> lower level primitives: is_little_endian? and byteswap. To standardize
> "make-it-this-endian" would leave the use cases needing simply byteswap out
> in the non-standardized cold. And yet it would be easy to _build_
> "make-it-this-endian" on top of is_little_endian? (now called `std::endian`
> in C++20) and byteswap.
Yes, but given that most uses *are* "make it this endian", it would be
silly to not have that as well. It's probably best to offer both.
-- Matthew
Received on 2021-02-26 11:43:40