Hi Robert On 8/10/06, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote:
over the next few days, i'm going to have some general design-type questions as i try to restructure a project i'm working on, so i'm hoping i don't wander too far from the mandate of the list.
Goodie !! I hope this will be as fun for us as it is for you !!
on this current project, there is frequent use of what i call "catchall" header files. rather than have individual source files pull in just those header files they need, a monster "catchall.h" file is created that contains almost all project-related inclusions, so that source files need only: #include "catchall.h" sure, it's convenient, but there are also some obvious downsides. the simple question -- is there a defensible rationale for this approach? i personally don't like it and would prefer source files to be more selective, but the argument i keep hearing is, "it's more convenient."
I use a similar design architecture in my project. I think the convinience factor comes in when the project is REALLY large and, more impostantly, spread out. In fact, in my project, I have a a heirarchy of these "catchall" header files. Eg. A module has a catchall file for all its sub-modules, A component has a catchall header file for all its modules, an interface for is components, a product for all its interface and components.... so on and so forth. I can't imagine being selective with the header files as I would end up with tens of 100s of LOC of only header file declaration. Not to mention the tediousness of the selection procedure. -- Raseel. http://osd.byethost8.com http://raseel.livejournal.com - : send the line "unsubscribe linux-c-programming" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
