On Jan 11, 2006, at 12:23 AM, Ralf Stephan wrote:
Did you do any passes to address #includes in .h files before removing them from .cpp files? If not, then we can probably just work on that as a next phase.
Ah thanks for mentioning that. After the orientation run, several hotspots were identified where bunches of specific includes were removed because a .h file contained a general one. Example: .h contains <gtkmm.h>, leads to removal of all specific <gtkmm/...> includes in cpp files.
Actually... that's the opposite of what might be best in many cases.
Removing #includes from the .h in general make each .h file more standalone, easier to substitute things in, and lets the .cpp files drive dependencies.
If it's a standard system include that is needed (e.g. <stdint.h>), its usually safe to assume that the consumer .cpp file will include that once at the top of its includes. It also allows for things like debug macros, wrappers and such to be added in localized situations. Often one can eliminate the need for nested #includes altogether with the judicious use of a few forward declarations instead. (Oh, but not quite the way that src/forward.h used to be)
Then, removing general <gtkmm.h> includes and just using specific <gtkmm/...> includes in .cpp files instead will vastly simplify dependencies and number of files to be included, even though the LOC is higher. On my current system, for example, including <gtkmm.h> immediately does a #include of one hundred and twenty-four other .h files. So by removing four LOC in each .cpp in favor the single shared line in the .h file, you get over a hundred extra includes for each consuming .cpp. Only including the bits you actually need can both simplify maintenance and also speed compile time.