OP's approach works if all dudes involved read the code before chaning it and stay off private parts even if they aren't guarded by the language constructs.

That's not how software development works in e.g. companies where multiple people use the software (framework, libraries, API's) at different levels/roles.

For example, if we develop some framework to be used at multiple sites in the company, we can be 100% sure that at some point someone will assume that anything marked 'public' in the API is fair game to use (which IMO is a reasonable perspective). If they start using internal API's or depend on class internals that are only public just because the language did not provide us with a reasonable way to hide them, at some point we will change them and working systems could break elsewhere. In a similar fashion, misuse of private API's by violating preconditions that are completely opaque to users of your (intended) public API can lead to the worst kinds of bugs and unpredictable runtime failures.

Software development always seems so simple and pragmatic if you don't need to care about other people you have no control over.

> That's not how software development works ...

... in your setup. All shops are different. To each their own. There's no private/protected scaffolding in the Linux kernel to give the most obvious example.

Well last time I checked the Linux kernel was C and not C++, so that might explain why ;-).

I don't know anything about kernel programming, but I assume that there's some very, very strict conventions about how the various parts of the Linux kernel interact, and nothing gets accepted for merging unless you follow them. This would be similar to imposing scope/visibility constraints at the language level, but considering C doesn't have anything for that, an extremely strict development process is the best you can do.

emm... All we could say is that, kernel programmers'/reviewers' technical background is much higher/better than average python programmers'/reviewers'. Seen too many times these "Mr/Mrs. More or less" engineers simply modify the internal states as short cuts to compensate real engineering.

Equally being too defensive and over-complicating code in case a "bad" developer makes a breaking change often leads to code that is worse in the long term.

So it's an implicit contract based on syntax vs explicit?

It's a user/m_ prefix vs compiler/private. Im not sure if former is better. It's a strong trade off imho.

In my experience relying on people reading code and agreeing on imlicit contracts does not scale beyond 5 people, but maybe I've been mistreated by life.

>if all dudes involved read the code before chaning it

And that's only ever possible if you're the only "dude", and your codebase is like <10k loc

No, not really. It works quite well for large projects too. Just look at any open source that is C-based.

The only mechanism for safe-guarding access to private parts is using privately defined structs that are passed around in a form of opaque pointers. Some project use it (PGPphone did, the original SSH did, etc.), some don't, e.g. BSD and Linux kernels.

It's really more of a matter of developers exercising some basic thought when using other people's code. And it just happens so that there's more of them outside of the C++ group than in it.