CppCheck & Clang-Tidy Comparisons

[Vince Bridgers]

Hello, I was wondering if some comparisons of CppCheck andClang-Tidy checks were available. For example, which checks are available inboth, and which checks are exclusive to CppCheck and Clang-Tidy. I understandboth tools are good, and a battery of Code Checking tools is the best way to go.

I’d like to understand this, since I’m wondering if it makessense to focus on certain types of checks in CppCheck and others usingClang-Tidy. Also, had there been some attempt to port some CppChecks over to Clang-Tidyor the other way around, to take advantage of the relative strengths of eachtool?

I understand from reading some past discussion points inthis forum, some developers do not like contributing to LLVM/Clang since theyfind the review process long and tedious, preferring to focus on CppCheck. Justwondering if there were any other considerations.

Thanks 

[Daniel Marjamäki]

I was wondering if some comparisons of CppCheck andClang-Tidy checks were available

It's hard to compare static analysis tools.

Maybe these are somewhat interesting:
http://btorpey.github.io/blog/2016/04/07/mo-static/
http://btorpey.github.io/blog/2017/09/17/lotso-static/

In my opinion there is not that much overlap in the tools so it's best to use all the tools that you can.

I’d like to understand this, since I’m wondering if it makessense to focus on certain types of checks in CppCheck and others usingClang-Tidy.

That can happen. I don't really know where the line is drawn. If you want to detect UB then that might fit well in both Clang-Tidy and Cppcheck. But then depending on how you want to detect it, it might fit better in Clang-Tidy or Cppcheck. For technical reasons and/or philosophical reasons.
Philosophical; if you can't detect the UB directly but want to warn about dangerous code that could lead to UB. Then you'll have to motivate your idea..
Technical: Both Clang-Tidy and Cppcheck has technical advantages so it might technically be better to put your check in one of the tools for technical reasons.

Also, had there been some attempt to port some CppChecks over to Clang-Tidyor the other way around, to take advantage of the relative strengths of eachtool?

I ported a few minor Cppcheck checks to Clang when I was a contractor. We sometimes add "compiler" warnings in Cppcheck even though I think it's kind of waste of time to reimplement those. Overlapping features have no value.

some developers do not like contributing to LLVM/Clang since theyfind the review process long and tedious

yes that is my opinion. there are two sides of course of this. With a long and tedious review process the quality gets higher.

I've had to rewrite Cppcheck infrastructure a couple of times because I learned the hard way there was limitations. While Clang infrastructure is still the same (just enhanced not rewritten), they designed it really well from the start.

[Markus Elfring]

I've had to rewrite Cppcheck infrastructure a couple of times because I learned the hard way there was limitations. While Clang infrastructure is still the same (just enhanced not rewritten), they designed it really well from the start.

Will this experience influence the corresponding software development any further in positive ways?