This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Include file structuring.


On Fri, Oct 18, 2013 at 10:00 AM, Andrew MacLeod <amacleod@redhat.com> wrote:

> The question is... Do we allow a .h file like this to be an aggregator,
> meaning a file can just include tree-ssa.h and get all this, or do we push
> it all down to the .c file, and actually include what each one needs.  Or do
> we pick a specific subset for tree-ssa.h...

In general, I'm a big fan of Include What You Use (IWYU). Files should
explicitly include everything they need. Moreover, header files should
not bleed onto each other. This means that they should be
self-contained (i.e., I should be able to re-order the set of
#includes in a given .c file without altering the semantics of the
TU).

In the case of headers, this is a double edge sword, on the one hand
you want to make it self-contained (so it should #include everything
it needs), and  at the same time you want to disallow headers to
#include other files.

As much as possible, I agree that we should not allow header files to
include other headers. Using forward type declarations can alleviate
this problem somewhat. But if the header has inline functions, you're
forced to include the other header it depends on.

IWYU is important in the long term so that we can take advantage of
C++ modules. For now, moving to a model where no header files include
other headers will allow us to fix modularity problems. This will give
us IWYU in .c files, we can later think about enforcing IWYU for .h
files.


Diego.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]