Re: [hash2][review] Early review (due to holidays)

From: Peter Dimov (pdimov_at_[hidden])
Date: 2024-12-06 17:49:55

Andrey Semashev wrote:
> Assuming you had code like this:
> 
>   void transform( span<unsigned char const, 64> block )
>   {
>     for( int i = 0; i < 16; ++i )
>     {
>       x[ i ] = detail::read32le( block.subspan(i * 4, 4) );
>     }
>   }
> 
> I would presume, the subspan call would have a runtime check for the offset
> and size. Then the converting constructor from span<const unsigned char>
> returned from subspan to span<const unsigned char, 4> accepted by read32le
> would have to check the size again. Yes, the compiler could optimize those
> checks away, if it's smart enough.

It could, yes. Giving the compiler the opportunity to elide the checks is the
point of the fixed extent span.

If you use dynamic extent spans everywhere, the compiler can't optimize
out the checks using only local knowledge, it will need to rely on inlining
and have to work quite a bit harder.