[PATCH] D48896: [libcxx][c++17] P0083R5: Splicing Maps and Sets Part 2: merge

Louis Dionne via Phabricator reviews at reviews.llvm.org
Wed Oct 24 14:12:15 PDT 2018


ldionne added a comment.

In https://reviews.llvm.org/D48896#1274919, @rsmith wrote:

> In https://reviews.llvm.org/D48896#1274779, @ldionne wrote:
>
> > When merging  a multi-container into a unique-container (e.g. `map.merge(multimap)` or `set.merge(multiset)`), I think we could do the following optimization: Once we've inserted an element from the `multimap` into the `map`, we could skip all the following equivalent elements in the `multimap` without having to perform a search in the `map` each time (since we know we won't insert the element anyway).
>
>
> We can only do that if the comparators divide elements into the same equivalence classes, which we cannot know in general. (We can do this optimization if we can prove the comparator is a pure stateless function, but we probably can't detect that -- even an empty class type could store its state outside the class.) However, if the source and destination have the same comparator, and that comparator is `std::less<T>`, then I think it's correct to do this optimization.


Ah, so you mean if the two comparators were both valid **but different** strict weak orderings? Yes, I guess that kills my optimization in the general case. I think it would be possible to enable the optimization whenever the comparators for the `map` and the `multimap` are both stateless (`std::is_empty`) and the same. Then, I don't see a way they could be different orderings. (Note that we'd have to prove that a stateless comparator can't break this optimization by using global variables, which I think can be proven)


https://reviews.llvm.org/D48896





More information about the libcxx-commits mailing list