Associative containers implements some of the algorithms as methods which
should be preferred to the algorithms in the algorithm header. The methods
can take advantage of the order of the elements.
Details
- Reviewers
alexfh - Commits
- rG3880bee0ff04: [clang-tidy] Checker for inefficient use of algorithms on associative containers
rCTE228505: [clang-tidy] Checker for inefficient use of algorithms on associative containers
rL228505: [clang-tidy] Checker for inefficient use of algorithms on associative containers
Diff Detail
Event Timeline
clang-tidy/misc/InefficientAlgorithmCheck.cpp | ||
---|---|---|
25 | What about unordered_(multi)?(set|map)? | |
38 | Maybe something along the lines of on(equalsBoundNode("IneffContObj"))? | |
69 | I'm not a native speaker, but the message seems a bit unclear. How about "different comparers used in the algorithm and the container"? Also, please remove the trailing period. | |
83 | A Twine can be used here instead. | |
97 | Please remove the trailing period. |
Thanks for the review.
- I have added support for unordered containers. There is no comparator check for the unordered containers and there is no lower or upper bound member functions. Code to deal with these cases was added.
- I made the matcher more strict with equalBoundNodes as you suggested.
- The warning messages was modified as you requested. Unfortunately I do not have a native speaker coworker to check these messages.
- Replaced the string concatenations with twine operations.
One nit, otherwise looks good. Please address the issue and I can commit the patch for you.
BTW, I think that it makes sense for you to apply for a commit access (http://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access).
Also, could you run the check on LLVM/Clang to see whether it finds something?
clang-tidy/misc/InefficientAlgorithmCheck.cpp | ||
---|---|---|
43 | Do you need to check this in addition to the equalsBoundNode above? |
Hi Alex,
Thank you for the review.I have removed the redundant checks you mentioned. I did run it on the LLVM code base and did not found any match. I think there is two reason: the code has exceptional quality and LLVM has it's own set of data structures. I will apply for commit access :)
clang-tidy/misc/InefficientAlgorithmCheck.cpp | ||
---|---|---|
22 | This turns out to match std::count_if/std::find_if as well. Could you surround the regex with ^$ and add a test? Same applies to the ContainerMatcher below. |
I found two more issues with this check:
- the fixes for map-like containers are wrong. The .begin() and .end() allow to iterate over values of the map, and .find() accepts a key. I don't know if there is a good fix for all cases where std::find-like algorithms are used on a map. Maybe just leave a warning without a fix?
- the check can produce incompilable fixes if an algorithm receives a value of a different type than the type of the container's elements. See http://pastebin.com/5pkMLrZb for an example.
Would be nice if you could fix the issues.
Thanks!
Thank you for the feedback. I think I should have seen the first problem in advance. I find the second one more subtle. Both should be fixed in r229552. I am not absolutely happy with the solution: checking for type equality modulo references. It would be better to check if appropriate type conversions exists, but I did not find a nice way to do it. What is your opinion?
This turns out to match std::count_if/std::find_if as well. Could you surround the regex with ^$ and add a test? Same applies to the ContainerMatcher below.