<flat_map>: Unwrap flat_(multi)map's iterators
#4650
Conversation
| return _RANGES equal(_Left_base._Data.keys, _Right_base._Data.keys) | ||
| && _RANGES equal(_Left_base._Data.values, _Right_base._Data.values); |
There was a problem hiding this comment.
Should we sometimes call _RANGES equal(_Left_base, _Right_base), especially when vectorization is unavailable?
There was a problem hiding this comment.
I think that even if the comparison is not vectorized, it may be still advantageous to avoid jumping between arrays, and have dedicated cache/prefetch use just for one array. Though this advantage looks not very significant though.
There was a problem hiding this comment.
I'm more wondering how this can work for multimap with equivalent keys with distinct values.
There was a problem hiding this comment.
I'm more wondering how this can work for multimap with equivalent keys with distinct values.
In flat_multimap, multiple equivalent keys are stored multiple times and each instance is grouped with it's corresponding value, so ranges::equal just works.
There was a problem hiding this comment.
But is order of values defined?
Like {4, 10}, {4, 20}, {4, 30} map can be stored like {4, 4, 4}, {10, 20, 30} or {4, 4, 4}, {30, 20, 10}
There was a problem hiding this comment.
The order of values depends on the order of insertion, as specified in [associative.reqmts.general]/68.
There was a problem hiding this comment.
I see. To me it looks not useful if multimap with the same pairs might happen inequal
Also - move-construct underlying iterators in the constructors of `flat_(multi)map`'s iterators; - fix and test `flat_(multi)map`'s comparison; - remove possibly pessimizing `reserve`, with signedness adjusted; and - simply `vector<T, allocator<T>>` to `vector<T>`.
frederick-vs-ja
force-pushed
the
unwrap-pairing-iter
branch
from
a3ecd7a to
b22f516
Compare
StephanTLavavej
added
bug
|
Thanks for flattening away these issues! 🚂 🥞 😹 |
3 participants
Also
flat_(multi)map's iterators;flat_(multi)map's comparison;reserve, with signedness adjusted; andvector<T, allocator<T>>tovector<T>.Address review comments in #4468; towards #2910.