Date: Mon, 22 Jun 2026 21:23:07 +0000
Here's my take on it.
The question on either or not it is even worth the committee's time is a fair observation regarding how trivial the feature is.
It's so trivial in fact that every single company that I worked had a version of it, they didn't bother to grab an existing library to do it, they just did it themselves, independently, over and over again, albeit with different levels of sophistication.
It’s a task I would be more than comfortable to give to a junior hiree, and expect them to successfully complete it in a day.
But one thing they all had in common is that they were not ranges or views.
I think that using a range is about the most inefficient way of doing this that I can think of.
The best way to solve this problem is to just write the data from the source that has the questionable endianness onto a buffer, and then directly do the endianness correction in place and forget about the fact that the source had it the wrong way around.
That is it!
I would be extremely surprised if you are able to find a popular piece of code that is actively used in which this isn't the case.
Just because you can write it as a range it doesn't mean you should.
Don't get me wrong the original concept of ranges was good, but I'm afraid that what it is evolving into is not, and nobody is questioning this.
Because it is easy to use and looks short on text, it is easy to forget how many layers have been piled on, and how convoluted the code path actually is.
It has just become a pile of slopy and apathetic code, and people don’t realize how much simpler it would have been and how much more efficient it would have been had you not done things this way.
That is my opinion.
________________________________
From: SG16 <sg16-bounces_at_[hidden]> on behalf of Jan Schultke via SG16 <sg16_at_[hidden]>
Sent: Monday, June 22, 2026 2:52:21 PM
To: Ville Voutilainen <ville.voutilainen_at_[hidden]>
Cc: Jan Schultke <janschultke_at_[hidden]>; sg16_at_[hidden] <sg16_at_[hidden]>; Tom Honermann <tom_at_[hidden]>; SG9 ranges <sg9_at_[hidden]>
Subject: Re: [isocpp-sg16] Thoughts on P4030R0: Endian Views
It sounds quite non-academic to me to apply an encoding-correcting
view on a memory-mapped range and therefore apply the endian
correction
only to the parts of the range I actually end up traversing.
I was under the impression that people typically use memory mapping to map e.g. a file onto a buffer of bytes, in which case being able to traverse a byte array with reversed endianness would provide more utility than just the quasi-transform-view that wraps byteswap.
The question on either or not it is even worth the committee's time is a fair observation regarding how trivial the feature is.
It's so trivial in fact that every single company that I worked had a version of it, they didn't bother to grab an existing library to do it, they just did it themselves, independently, over and over again, albeit with different levels of sophistication.
It’s a task I would be more than comfortable to give to a junior hiree, and expect them to successfully complete it in a day.
But one thing they all had in common is that they were not ranges or views.
I think that using a range is about the most inefficient way of doing this that I can think of.
The best way to solve this problem is to just write the data from the source that has the questionable endianness onto a buffer, and then directly do the endianness correction in place and forget about the fact that the source had it the wrong way around.
That is it!
I would be extremely surprised if you are able to find a popular piece of code that is actively used in which this isn't the case.
Just because you can write it as a range it doesn't mean you should.
Don't get me wrong the original concept of ranges was good, but I'm afraid that what it is evolving into is not, and nobody is questioning this.
Because it is easy to use and looks short on text, it is easy to forget how many layers have been piled on, and how convoluted the code path actually is.
It has just become a pile of slopy and apathetic code, and people don’t realize how much simpler it would have been and how much more efficient it would have been had you not done things this way.
That is my opinion.
________________________________
From: SG16 <sg16-bounces_at_[hidden]> on behalf of Jan Schultke via SG16 <sg16_at_[hidden]>
Sent: Monday, June 22, 2026 2:52:21 PM
To: Ville Voutilainen <ville.voutilainen_at_[hidden]>
Cc: Jan Schultke <janschultke_at_[hidden]>; sg16_at_[hidden] <sg16_at_[hidden]>; Tom Honermann <tom_at_[hidden]>; SG9 ranges <sg9_at_[hidden]>
Subject: Re: [isocpp-sg16] Thoughts on P4030R0: Endian Views
It sounds quite non-academic to me to apply an encoding-correcting
view on a memory-mapped range and therefore apply the endian
correction
only to the parts of the range I actually end up traversing.
I was under the impression that people typically use memory mapping to map e.g. a file onto a buffer of bytes, in which case being able to traverse a byte array with reversed endianness would provide more utility than just the quasi-transform-view that wraps byteswap.
Received on 2026-06-22 21:23:10