On Mon, 22 Jun 2026 at 11:37, Robert A.H. Leahy <rleahy_at_[hidden]> wrote:

> I don't understand how anything about the problem domain implies that I
> need to eagerly convert endianness.
>
> In order to use the data I need to convert the endianness, but that
> doesn't mean that I need to eagerly do so since it's not a given that I
> will use the data.
>

If your use case is that you want to avoid processing all the data but only
want to examine e.g. one line of a text file, you can equally accomplish
that by searching for that line and then eagerly converting that one line.

And anyway, the common use case is that I have some serialized data and I
decode it into something I can actually use in my application. The use case
where you do that on-demand is highly specialized in my opinion, and it
incurs major complexity cost to deserialize file portions on-demand (which
views might be useful for).


> Also note that since the functionality we're talking about is presented in
> the form of a view, and therefore we're in the domain of ranges, nothing
> about constructing such a pipeline implies that conversion will actually
> occur. Loading the "wire"-endian data might be lazy in the same way the
> endianness conversion is.
>

This would be more motivating if endianness conversion was more expensive.
Then you could avoid this super expensive operation if you first had a
views::filter in the pipeline, or something like that.

However, we're talking about something that's either a no-op or a
single-cycle bswap instruction.

And if your goal is to only endian-convert a subrange of the data, that can
equally be accomplished without views.



> Note that representing the wire-endian data by its destination type,
> rather than by bytes, allows for the view pipeline to discover the type
> implicitly, rather than having to restate it. This technique is also used
> by the interface of Boost.Endian (i.e. I don't need to explicitly tell
> boost::endian::big_to_native that it's converting to std::uint16_t because
> I pass it a big-endian std::uint16_t and it can use template argument
> deduction to discover this).
>

Okay, but Endian Views don't provide this functionality of representing as
the type rather than as bytes. You still need to do all the chunking and
joining and reinterpreting yourself before you even get to use an endian
view. I'm more interested in solving that part.

Thankfully, Boost.Endian also provides endian_load and endian_store
functions, which I find much more relevant.

>