"Big ball of mud" dependency structures are common because the most pragmatic quick-fix for so many compile errors it to just whack in a new #include.

C++ is worse than most languages in this way, because private members are defined in public headers. This forces you add #includes to the headers. Thus the #include graph is much denser than the true dependencies in your program.

There's tricks for getting around this, but they aren't always practical; and they go against the grain of the "every class has its own .cpp and .h file" rule, which lots of people want to insist on.

>There's tricks

You mean PIMPL?

Yes, I think so, though I was never truly clear on what PIMPL was supposed to mean.

I am referring to writing a base class in the header and then doing the actual implementation in a derived class visible only inside one .cpp file. There are some other tricks you can do too, such as using pointers-to-incomplete types.

When I do any of these tricks, find that someone else later comes and makes a changes that introduces the extra #includes after all.

PIMPL means "pointer to implementation" and the reason you and your colleagues are having difficulty with it is because you don't understand it, and therefore should not be using it, or, investing the time to understand it before trying to use it.

>every class has its own .cpp and .h file

Wrong. There are so many high-quality and widely-used libraries that are "header only".

>When I do any of these tricks, find that someone else later comes and makes a changes that introduces the extra #includes after all.

It is possible to write sloppy code in any language, and also to receive low-quality contributions from anyone else to your code. This is not unique to C++. That's why it is important that everyone in a team be on the same page about how code is organized.

>I am referring to writing a base class in the header and then doing the actual implementation in a derived class visible only inside one .cpp file.

This is not the PIMPL idiom, though it is halfway right.

PIMPL pattern is great for reducing compilation time and creating stable user-facing APIs but it has a runtime cost. The "implementation" part is usually heap allocated and calling its methods have extra overhead of crossing the pointer to implementation barrier.

With the use of link-time optimization, most of the overhead of using pimpl idiom is removed. Both the outter wrapper functions as well as the implementation functions can be inlined, making the function calls effectively like a normal class implemented inside a header.

The heap allocation for the implementation won't be removed by LTO.

I'm inclined to agree that for objects that are going to be created and destroyed very often, especially in tight loops, PIMPL is not an ideal idiom. I wouldn't use it to generate fleeting effects in graphics, for example.

For objects that are used in setting up parts of a system and that will persist for long periods of time, maybe even the lifetime of the app, PIMPL is particularly well-suited for such classes. Classes that might manage networking, or encompass an entire part of app's running architecture, etc.

Thw complexity and overheead of PIMPL is justified in one scenario, and one scenario only - when you are writing a shared library and need to maintain a stable ABI. Otherwise it is complete overkill.

In my experience both have been true. That's why you get 10+ minute link times in some projects, so even if you use Incredibuild to compile, it still takes ages to link.