[mpl] at<> behaves differently for vector_c<> and vector<>
I asked earlier in a post "[mpl] Working with map, copy and back_inserter".
This is a related question. The common question is: What does compile-time
equality means in MPL, particularly for map and set key equality? Does it
mean std::is_same? The following code works whether USE_VECTOR_C is defined
as 0 or 1 -- the last 2 lines are static_asserts that have conditions
determined by USE_VECTOR_C so that they succeed, highlighting the
difference in behavior between USE_VECTOR_C == 0 and USE_VECTOR_C == 1.
USE_VECTOR_C == 0 is the normal case where everything is working as I
expect. USE_VECTOR_C == 1 is the unexpected case where the static_asserts
in the last 2 lines have conditions altered so that they succeed.
Why do vector_c and vector give me different "element values"? In general,
what should I be careful about when trying to use the "compile-time values"
as keys to avoid the situation elucidated by the last line, where I expect
two "compile-time values" to be the same but they are not, resulting in two
set/map items instead of one?
To clarify, I'm using boost 1.63 with gcc 6.3.1 and -std=c++14 on Arch
Linux.
Josh
#include
AMDG On 02/05/2017 04:09 AM, ☂Josh Chia (謝任中) wrote:
I asked earlier in a post "[mpl] Working with map, copy and back_inserter".
This is a related question. The common question is: What does compile-time equality means in MPL, particularly for map and set key equality? Does it mean std::is_same?
Yes.
The following code works whether USE_VECTOR_C is defined as 0 or 1 -- the last 2 lines are static_asserts that have conditions determined by USE_VECTOR_C so that they succeed, highlighting the difference in behavior between USE_VECTOR_C == 0 and USE_VECTOR_C == 1. USE_VECTOR_C == 0 is the normal case where everything is working as I expect. USE_VECTOR_C == 1 is the unexpected case where the static_asserts in the last 2 lines have conditions altered so that they succeed.
Why do vector_c and vector give me different "element values"?
MPL has multiple distinct types that represent
the same integral constant. integral_c
In general, what should I be careful about when trying to use the "compile-time values" as keys to avoid the situation elucidated by the last line, where I expect two "compile-time values" to be the same but they are not, resulting in two set/map items instead of one?
In Christ, Steven Watanabe
participants (2)
-
Steven Watanabe
-
☂Josh Chia (謝任中)