Clang's scan-build supports C++ for a long time already.

Regarding gcc/g++, there seems to be support only for C. From https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer:

> Initial implementation was added in GCC 10; major rewrite occurred in GCC 11. > Only C is currently supported (I hope to support C++ in GCC 13, but it is out-of-scope for GCC 12)

Looking forward to seeing C++ support added to it!

The major benefit to "tool is part of the compiler" is that vastly more people will use it and maybe fix the errors. There's a Google paper from 2018 (https://m-cacm.acm.org/magazines/2018/4/226371-lessons-from-...) about their experience with static analysis tools, and what they found was that the better the analysis was integrated with the existing developer workflow and the earlier the issues were noted, the more likely they were to actually be fixed. So "existing compiler reports the errors" is better than "tooling reports the errors as comments in the existing code review system" is better than "tooling files bugs in the existing bug tracking system after new code is already committed" is better than "tooling has its own separate dashboard that nobody looks at".

I don't care whether under the hood the implementation is fully part of one big "compiler" engine or not, in the same way I don't care that when I run 'gcc' it's really running a compiler, assembler and linker which are all self-contained programs -- I do care that when I say "build my code" in the usual way that that is when analysis happens.

Basically because since 1979 the dividers keep failing to use lint.

"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions. "

https://www.bell-labs.com/usr/dmr/www/chist.html

Lumpers probably account for 90% of the market and users. Dividers like to tweak and usually have to fix problems with the many tweaked fixes to get disparate tools to work together. Lumpers like to focus on their problem domain and not fuss with perfection and ultra-optimal solutions that deliver unquantifiable cost/benefit returns.

I say this fondly though as a recovering Divider who still appreciates the pioneering spirit of Dividers.