[PATCH] D146061: [ADT] Make llvm::is_contained call member `contains` when available
Fangrui Song via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Mar 14 17:19:44 PDT 2023
MaskRay accepted this revision.
MaskRay added a comment.
In D146061#4194866 <https://reviews.llvm.org/D146061#4194866>, @kuhar wrote:
> In D146061#4194853 <https://reviews.llvm.org/D146061#4194853>, @nikic wrote:
>
>> In D146061#4194752 <https://reviews.llvm.org/D146061#4194752>, @kuhar wrote:
>>
>>> Sure, I agree with that. If I have map with a known type like `DenseMap` I'd rather call `.contains(x)` directly too. But this is not possible with C++17 containers `std::`, so I'd argue that until then `is_contained(container, x)` is more readable than something like `container.find(x) != container.end()`.
>>
>> I don't think we should promote usage of is_contained() for anything but the linear scan case. I don't want to be left guessing whether this is_contained() is a linear scan, or just a slightly different way to write container.find().
>
> I can see this being prefered from the perspective of an experience llvm developer, but on the other hand I saw a lot of code that ended up using `is_contained` and `llvm::find` with map/set types. I found fixing those inefficiencies and re-explaining this to folks needlessly time consuming. I think defaulting to the more efficient implementation of containment check is the way to go to avoid those non-obvious performance issues, and the member functions we would delegate to are not surprising at all.
Agreed with the analysis.
================
Comment at: llvm/unittests/ADT/STLExtrasTest.cpp:1039
+ return ContainsResult;
+ }
+ bool ContainsResult = false;
----------------
Add a `find` to show that `contains` is preferred.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D146061/new/
https://reviews.llvm.org/D146061
More information about the llvm-commits
mailing list