etl::span: Add advance(), copy(), reinterpret_as()

[rolandreichweinbmw]

This commit adds to etl::span:

• advance()
• copy()
• reinterpret_as()

including tests.

[jwellbelove]

Is the purpose of reinterpret_as to map, for example, a buffer of char to a range of int, and the other way round?
Shouldn't there to be a check for size multiple and possibly alignment, so that, say, seven int8_t at an odd alignment cannot be reinterpreted as a unit32_t?

i.e.

etl::array<int8_t, 7> buffer;
etl::span<int8_t) sp1(buffer.begin(), buffer.end());
auto sp2 = sp1.reinterpret_as<unit32_t>();

uint32_t i = *sp2.begin(); // Is this aligned correctly!

[rolandreichweinbmw]

Right. I will add this.

[jwellbelove]

This is a class member function, but it copies between two other spans.
This would be better implemented as a separate standalone function, or maybe as a member copy_to(dst)

[rolandreichweinbmw]

Are you sure?

As far as I can see, this free function etl::copy(), actually an overload, is outside the class, similar to the directly above etl::equal().

What is strange here is the line numbering. When I merge it on top of current master, it ends up in l.968, not l.830.

[jwellbelove]

Sorry, I see that it is already a standalone function. I got confused looking at diff view late last night. It made the copy function look like a member of the class.
I looked at the full file view this morning.

[jwellbelove]

You can use etl::alignment_of instead of alignof which works for C++03.

[rolandreichweinbmw]

Thanks for the hint! Updating it accordingly.

[rolandreichweinbmw]

Regarding your remark about odd-numbered spans where you get rounding errors when reinterpreting: This is intended, and considered a feature. Consider the case of having a buffer from some protocol data, and only a part of it is the respective span, i.e. value array. Then the size is automatically rounded down to the next correct size, and we can only correctly assume the initial whole elements to be valid, and discard the rest:

• "If pend - pbegin is 3 bytes and TNew is an int32_t then the size of the new span is 0." - Yes, as expected.
• "If pend - pbegin is 6 bytes and TNew is an int32_t then the size of the new span is 1, with 2 bytes before pend." - Yes, as expected
• "An advance of the int32_t span pbegin pointer would never equal pend, meaning loops of the return span would never terminate." - No, because the expected new size 1 leads to pbegin and pend to be set correctly, with pend discarding the bytes you mentioned in the first 2 cases.

I added further unit tests for reinterpret_as() to show what I mean.

[jwellbelove]

Yes, I realised that after I wrote the comment. I deleted the comment.

[rolandreichweinbmw]

After rebasing onto latest ETL with new unaligned_type, I encountered failing unit tests for reinterpret_as() on Windows.

It was caused by the new multiple inheritance of unaligned_type because sizeof() now results in additional bytes counted for the second base class unaligned_copy which contributed an additional byte. (Even though empty class - but looks like 1 byte is reserved for that.)

My solution in the branch is the change to single inheritance, moving unaligned_copy to a class member typedef. Including tests for that.