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]

Re: new switch that warns about missing includes


[Alexandre Oliva]
> 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.
Yes, this looks nice for me, too. As a programmer I am looking at the
headers to get information about the declared things. For C++ this
becomes more and more complicated. If each header would describe which
names it declares it would be very nice for programmers.

> 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>.
Yes, this make things even more complicated.

> 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.
Yes, I don't respected transitivity in my proposal.

> 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.

It is hard to implement, nevertheless would it be possible to list
this on the projects homepage so it is not forgotten:
http://gcc.gnu.org/projects/

Or is it a too unimportant and not wanted feature for GCC?

Best regards,

Florian Schintke
-- 
Florian Schintke <schintke@zib.de>, http://www.zib.de/schintke/


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