Re: [Boost-users] [MPL][MP11] Return value of at_c for out of range index

Subject: Re: [Boost-users] [MPL][MP11] Return value of at_c for out of range index
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2019-03-05 14:33:06

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