Yes, they are. 1) They add fragility. It's all too easy to take a dependency on code without explicitly stating it. I'm using objects from "b.h" by including "

Yes, they are. 1) They add fragility. It's all too easy to take a dependency on code without explicitly stating it. I'm using objects from "b.h" by including "a.h" which include "b.h" but I don't realize it. 2) They bring extraneous data into the code. A #include says more about the structure of your files than it may about the logical relationships between objects. Where to get things for the build is a job for the build config/system, not your business logic. 3) They're easy to use poorly. From your first circular include to the time you have to sort out a crawling build brought on by a bloated include tree, you'll swear there's gotta be a better way. They are good for some people though; there's a small cottage industry that's built around resolving the myriad irritations headers bring.