Re: new switch that warns about missing includes

[Alexandre Oliva <aoliva at redhat dot com>]

On Aug  8, 2001, Florian Schintke <schintke@zib.de> wrote:

> I think a switch that can warn about such dependencies would be
> very nice and should suggest to include <string> in b.hh because
> std::string occurs directly in b.hh. 

I believe that, instead of encoding the information about where each
name is defined in the compiler, it would be simpler to just have some
way to declare that certain names are declared in certain headers.
For example, <string> could contain:

#pragma GCC declares std::string

Then, information would remain self-contained in the library, and the
compiler wouldn't have to be modified in case something changes in the
library.  Also, the library would be more self-documented in terms of
C++ Standard compliance.

However, there is a problem in warning when a file uses a name without
having previously included the header in which the name is expected to
be declared.

One of the cases is in the implementation of the library itself: the
internal header file that implements std::string should not have to
#include <string>.

The other situation is that there are projects that define a single
header file that includes a number of other header files required all
over the project.  You address this with the include-for-propagation
pragma, but I'm not sure this would be an appropriate solution.  For
example, there is header b.hh that includes a.hh that declares a name.
c.hh includes b.hh and doesn't include a.hh because b.hh is documented
to includes a.hh.  But then, d.cc includes c.hh and uses the name
declared in a.hh without #including it.  I'd rather have a warning
about this, in case it is not documented that c.hh includes b.hh,
i.e., if c.hh doesn't explicitly document, with a different pragma,
that it always will transitively include a.hh and, if it doesn't, this
should be generate a warning.

However, this is tough to implement.  Suppose that b.hh is guarded by
include-once #ifndef/#define/#endif, and that b.hh is included by d.cc
before c.hh.  When the preprocessor gets to the point where c.hh
includes b.hh, even though it's not going to process b.hh again, it
must remember that b.hh would have included a.hh, and would have
brought in all declarations of names in a.hh again.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me