3 ms·
I think I agree that includes-within-includes are probably a necessity. But I am not that it allows things to be broken into "simple headers with easy-to-read
by adrianratnapala 10y ago
I think I agree that includes-within-includes are probably a necessity.
But I am not that it allows things to be broken into
"simple headers with easy-to-read APIs". That is true for headers that are small and only #include system headers and other basic dependencies. But if your own code has a nest of interelated headers, then a single big header file is probably easier to read.
- DSMan195276 10y agoWell I mean, perhaps I should have clarified, "simple headers with easy-to-read APIs" has to be looked at on a case-by-case basis and what makes sense. I would argue that as a general rule it is what you should aim for if possible (And I find it is possible in a lot of cases, and that if it's not things may be getting a bit too interconnected), but you're right that there are situations where things are a bit too complicated to split-up easily so a single header for multiple things makes sense. I think that if you're constantly in that situation though, you should reevaluate how you're designing your components and headers.