Boost logo

Boost :

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-12-06 22:09:07


On 12/7/24 00:51, Claudio DeSouza via Boost wrote:
>
> On Fri, Dec 6, 2024 at 9:47 PM Andrey Semashev via Boost <
> boost_at_[hidden]> wrote:
>
>> On 12/7/24 00:42, Vinnie Falco wrote:
>>> On Fri, Dec 6, 2024 at 1:38 PM Andrey Semashev via Boost
>>> <boost_at_[hidden] <mailto:boost_at_[hidden]>> wrote:
>>>
>>> Unless this is a new addition, I don't see such a member in
>> std::span.
>>>
>>> https://en.cppreference.com/w/cpp/container/span/subspan <https://
>>> en.cppreference.com/w/cpp/container/span/subspan>
>>
>> Ah, yes, I missed this, thanks.
>>
>> Anyway, it doesn't work as the offset is a runtime value in this case.
>>
> So to go back to my point: If you really want to avoid checks, and you do
> know the size beforehand, you can entirely avoid it by harnessing this
type
> of compile-time information and leveraging the compiler in your favour. It
> all depends how dedicated you are to make sure you get that. Granted, with
> dynamic extent the number of checks will depend on several factors,
> including implementation, and hardening settings the user is building
with.
>
> It is win after win with span.

To convert all the checks that are done in runtime with the code I
presented earlier you would have to convert that loop to a series of
statements such as this:

  x[ 0 ] = detail::read32le( block.subspan<0, 4>() );
  x[ 1 ] = detail::read32le( block.subspan<4, 4>() );
  x[ 3 ] = detail::read32le( block.subspan<8, 4>() );
  x[ 4 ] = detail::read32le( block.subspan<12, 4>() );
  // ...
  x[ 15 ] = detail::read32le( block.subspan<60, 4>() );

Or perform some kind of tricks with variadic templates and fold
expressions. At least, until `template for` (P1306) is accepted. So, I
suppose, it is doable in this limited case. But not something I would
willingly do, given that I can achieve the same result with a plain loop
and pointers. There's your example of span getting in the way.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk