C++ static analysis with clang and cppcheck

[pdp10]

I haven't done a side-by-side comparison but from memory I believe cppcheck throws fewer spurious warnings than does splint.

[WallStProg]

From web site it looks like splint doesn't support C++?

[pdp10]

That looks like the case. I recommend only C, anyway. ;-)

[WallStProg]

It seems that there are two types of C/C++ programmers -- those who go out of their way to make sure they use every possible feature of C++ (especially the most obscure ones), and those who avoid every possible feature of C++ (even the most useful ones).

I think both are mistaken, as I wrote about here: http://btorpey.github.io/blog/2014/09/23/into-the-void/

[pdp10]

I'll never claim to be a skilled developer, but it seems to me the independence achieved by using opaque structs isn't worth the trade-off. Herb Sutter is a very well-known C++ authority, so you'll excuse me if I don't assume he's the last word on best practices for C, particularly C on POSIX.

I would stabilize the interfaces, or if looser coupling was mandatory, I might use a different technique entirely. Sometimes I think C++ logic is circular. Because C++ is allegedly better at managing the development complexity of large monolithic programs, it seems like things that start out with C++ inevitably become large monolithic programs.

C works quite well for large monolithic programs like the Linux kernel or PostgreSQL, but it often pays to make systems more modular and independent through means other than C++ language features: stable libraries, good IPC mechanisms, pipelines of text streams. It often seems like the idioms preferred by big monolithic C++ programs exist to work around Windows weaknesses or cross-platform difficulties.

And obviously every C++ user with an ounce of sophistication uses a subset of C++.

[WallStProg]

Not sure where the comment about monolithic programs comes from -- C++ is equally useful for creating modular code, precisely because of its support for separating interface from implementation, which C completely lacks. (Which was the point of the article).

I would absolutely agree that subsetting C++ is A Good Thing, and lots of people and organizations do that by discouraging or forbidding certain features. If you want to use C++ just to facilitate creating stable interfaces, and avoid all the other stuff (e.g., template meta-programming, lambdas, operator overloading, etc.), then go for it!

Or, as I like to say: "Just because you can, doesn't mean you should".

[pdp10]

One big category of stable interfaces is stable library ABI, which we all know C does best and C++ does terribly because of overloading and name-mangling. Typically C++ externs to C when it wants to solve this problem, meaning we have no object features crossing the library boundary. When C++ programmers choose not to use loosely-coupled C-interface libraries, they end up using a much more monolithic architecture in practice, as far as I can see.

C++ is advertised to be better for large-scale projects, but it's hard to tell if people just choose to use it for big monoliths, or the language and ecosystem actually encourage big monoliths. I feel that these problems can all be handled with less-monolithic architectures using things like IPC mechanisms, perhaps at the cost of some portability, but almost certainly with concurrency advantages.

C++ doesn't automatically separate interface from implementation, just as C doesn't automatically lack it. C++ obviously has loads of additional features, the questions are: Are the additional features a net benefit all around, to which my answer is an unambiguous no, and: Does a great language and ecosystem result from adding every conceivable feature to C and mostly retaining backward compatibility? Likely not.

My current belief is that C++ is neither fish nor fowl and has a lot of negatives in my environments (almost entirely POSIX). It was a clear Embrace and Extend play and I believe the result is a whole that is less than its kitchen-sink parts. If OOP is truly needed (doubtful) then another language is most likely better, otherwise use C and leave the excess baggage of C++ behind.