`as_array_view` for types with alignment requirement about gsl HOT 6 CLOSED

That's a good point, rkawulak! Would you be interested in submitting an appropriate change as a PR?

from gsl.

I could, but I'm not sure which approach is better. Allowing only for types with no alignment requirement would be much more restricting, but OTOH would be verifiable statically rather than only at runtime.

from gsl.

I think a bool template parameter on array_view that defaults to true can be used. If the argument for this parameter is true, then a runtime check is done.

from gsl.

I thought about this a bit further. If someone is using array_view to move to/from a byte representation, then it is their responsibility to ensure that the alignment requirements for their environment will be met. So I'm going to leave this implementation as-is.

Moving to/from byte representations is useful, but risky behavior at the best of times and - as it would be if the user was using reinterpret_cast themselves - it is up to the user to ensure it is safe to do so.

from gsl.

Makes sense for array_view. However, when the source array view element type isn't byte, it might be helpful to have a static_assert on the alignment. Would that be too noisy?

from gsl.

@neilmacintosh Then what's the point of those as_array_view functions if not to help catching misuse like that? Otherwise they would be of little use since the user can invoke reinterpret_cast by himself and make the dangerous operation more explicit.

BTW, as I understand it is not about MOVING to/from byte representation, but about INTERPRETING byte representation as objects IN PLACE. If you want to use raw bytes as an object, you either need to make sure the bytes are properly aligned (this is what a runtime alignment assert could verify) or, if you cannot control how the bytes are aligned (e.g. you got a buffer with raw frames from a networking layer) and you want to avoid copying the bytes in order to realign them properly, the only option is to only allow for reinterpretation as a type with no alignment requirement, which is rather quite constraining.

BTW2, I think is_trivial check would be more suitable than is_standard_layout when dealing with interpretation of raw bytes as objects in a standard-conforming way.

from gsl.