Andrey Semashev wrote:
Assuming you had code like this:
void transform( span
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
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.