[MPL][MP11] Return value of at_c for out of range index
Hi, While porting some code from MPL to MP11, the latter helped to find some bugs in the ported code [1] I looked closer at those and found 'behavioural' differences between MPL and MP11 when accessing sequences with index value that is out of range. Could anyone help me to understand the following? 1. Why this compiles? using R = at_c<range_c<int, 0, 1>, 100>::type; Tested in C++11 using GCC, clang, MSVC from VS2017/2019 2. Why this compiles in GCC and clang, but fails with MSVC? using V = at_c<vector3_c<unsigned, 1, 2, 3>, 100>::type::type; 3. For GCC and clang, why this compiles static_assert(std::is_same<R, integral_c<int, 100>>::value, ""); but this fails? static_assert(std::is_same<V, integral_c<unsigned int, 100>>::value, ""); Don't vector_c and range_c yield equivalent sequences? By the way, MP11's mp_at_c yield void, as expected, there also no ::type or ::value member, so diagnostics is clearer. [1] https://github.com/boostorg/gil/issues/249 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
AMDG On 3/4/19 2:41 PM, Mateusz Loskot via Boost-users wrote:
Hi,
While porting some code from MPL to MP11, the latter helped to find some bugs in the ported code [1]
I looked closer at those and found 'behavioural' differences between MPL and MP11 when accessing sequences with index value that is out of range.
Could anyone help me to understand the following?
1. Why this compiles?
using R = at_c<range_c<int, 0, 1>, 100>::type;
Tested in C++11 using GCC, clang, MSVC from VS2017/2019
It compiles because there's no range check. It isn't something that you're supposed to do, however.
2. Why this compiles in GCC and clang, but fails with MSVC?
using V = at_c<vector3_c<unsigned, 1, 2, 3>, 100>::type::type;
It's essentially equivalent to: auto V = std::vector<int>{1, 2, 3}[100]; which has undefined behavior. It would be better if it consistently produced an error, of course, but the short answer is don't do that.
3. For GCC and clang, why this compiles
static_assert(std::is_same<R, integral_c<int, 100>>::value, "");
but this fails?
static_assert(std::is_same<V, integral_c<unsigned int, 100>>::value, "");
Don't vector_c and range_c yield equivalent sequences?
They're only equivalent if you say within bounds.
By the way, MP11's mp_at_c yield void, as expected, there also no ::type or ::value member, so diagnostics is clearer.
Yep. In Christ, Steven Watanabe
On 19-03-04 14:53:26, Steven Watanabe via Boost-users wrote:
On 3/4/19 2:41 PM, Mateusz Loskot via Boost-users wrote:
While porting some code from MPL to MP11, the latter helped to find some bugs in the ported code [1]
I looked closer at those and found 'behavioural' differences between MPL and MP11 when accessing sequences with index value that is out of range.
Could anyone help me to understand the following?
1. Why this compiles?
using R = at_c<range_c<int, 0, 1>, 100>::type;
Tested in C++11 using GCC, clang, MSVC from VS2017/2019
It compiles because there's no range check. It isn't something that you're supposed to do, however.
Yes, I do realise, and there is no place I do that intentionally. The code I presented leads to that usage by accident, a bug, where non-existent type is accessed from the range_c-generated sequence via at_c.
2. Why this compiles in GCC and clang, but fails with MSVC?
using V = at_c<vector3_c<unsigned, 1, 2, 3>, 100>::type::type;
It's essentially equivalent to: auto V = std::vector<int>{1, 2, 3}[100]; which has undefined behavior.
Right, the UB explains the results I'm observing.
It would be better if it consistently produced an error, of course, but the short answer is don't do that.
Roger that and thank you. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Fingerprint=C081 EA1B 4AFB 7C19 38BA 9C88 928D 7C2A BB2A C1F2
participants (3)
-
Mateusz Loskot -
Steven Watanabe