🚀 go-pugleaf

In article <4gj0p3$lp0@solutions.solon.com>, tonyh@tcp.co.uk says...
>
>Does anyone know of a PD tool available with portable(ish) source for
>removing surplus #include directives? For example:
>
>/* "file2.h" */
>#include "file1.h"
>
>-------------------
>
>/* "file3.h" */
>#include "file1.h"
>#include "file2.h"
>
>-------------------
>
>#include "file1.h" could be removed from "file3.h". This sort of thing
>saves a lot of compiler time without having the chore of typing:
>
>#ifndef __file1_h
>#include "file1.h"
>#endif
>

So, you mean that in the future if you decide that file2.h do not
need to include file1.h any more, you have to somehow remember 
to go back to file3.h and add a line to include file1.h, since may
be file3.h needs file1.h but file2.h do not need file1.h

Having to deal with these sort of things will most likley be not worth
the effort. Also remember that all this work with including .h files
is done by the pre-processor, not by the compiler itself.

>
>I know I will still need to do:
>
>/* "file1.h" */
>#ifndef __file1_h
>#define __file1_h
>/* Body of file */
>#endif
>
>but having an additional check around any #include directives or not
>doing the include at all saves the compiler lots of time having to load
>a file it's already included.
>

I think you are trying to save few nanoseconds here from the 
pre-processor time, but you will end up instead wasting more time
later when things break during compiling becuase you somewhere
have removed an include statment from one .h file that another file 
needed becuase the other file has including the file that removed the 
include statment from and it has assumed that that file will be there
but it is not in there any more.

You also have to remember to "run" this tool every time befor you run
the compiler, which means more tools to woorry about and manage and the
build environment will get more complicated.

If I where you, I'll have each .h file include every .h file that it
needs. If one of the files it includes happen to include one of the
files allready, then that is what #ifdef stuff for.

Now, others might think this tool is a good idea, I think it is not.

IMHO .

Nasser

{ I removed comp.lang.c.moderated from the newsgroups line as crosspostig
  is currently under review -mod}


      [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
      [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
      [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
      [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]

In article <4gum81$hlk@netlab.cs.rpi.edu>
          nababs@qualcomm.com (Nasser Abbasi) wrote:

> In article <4gj0p3$lp0@solutions.solon.com>, tonyh@tcp.co.uk says...
> >
> >Does anyone know of a PD tool available with portable(ish) source for
> >removing surplus #include directives? For example:
> >
> >/* "file2.h" */
> >#include "file1.h"
> >
> >-------------------
> >
> >/* "file3.h" */
> >#include "file1.h"
> >#include "file2.h"
> >
> >-------------------
> >
> >#include "file1.h" could be removed from "file3.h". This sort of thing
> >saves a lot of compiler time without having the chore of typing:
> >
> >#ifndef __file1_h
> >#include "file1.h"
> >#endif
> >
> 
> So, you mean that in the future if you decide that file2.h do not
> need to include file1.h any more, you have to somehow remember 
> to go back to file3.h and add a line to include file1.h, since may
> be file3.h needs file1.h but file2.h do not need file1.h
> 
> Having to deal with these sort of things will most likley be not worth
> the effort. Also remember that all this work with including .h files
> is done by the pre-processor, not by the compiler itself.

I think I'm inclined to agree with you now, but I don't understand your
point about the work being done by the preprocessor, not the compiler.
I'll stick to surrounding each include with an #ifndef.

> I think you are trying to save few nanoseconds here from the 
> pre-processor time

It takes more than nanoseconds.

-- 
Tony Houghton                     tonyh@tcp.co.uk
Using an Acorn RiscPC 700         http://www.tcp.co.uk/~tonyh/
No Intel inside, no Microsoftware. A computer, not a cartel.
----------------------------------------------------------------
The Internet is a most invaluable resource for Internet software

      [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
      [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
      [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
      [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]

In article <4h2kto$c9k@netlab.cs.rpi.edu>,
Tony Houghton  <tonyh@tcp.co.uk> wrote:
>In article <4gum81$hlk@netlab.cs.rpi.edu>
>          nababs@qualcomm.com (Nasser Abbasi) wrote:
>
>> In article <4gj0p3$lp0@solutions.solon.com>, tonyh@tcp.co.uk says...
>> [...desire for a tool to remove surplus #includes...]
>> I think you are trying to save few nanoseconds here from the 
>> pre-processor time
>
>It takes more than nanoseconds.

It also generates spurious dependecies that can cause entire files to be
recompiled because a header file they have no interest in has been touched.
If this happens in an unfortunate header file, the results of that can easily
propagate through large parts of your project and waste kiloseconds.

A file should contain exactly the header files it depends on, no more and
no less. If removing a #include causes you to add it somewhere else, you
were relying on a non-local and confusing inclusion structure anyway, which
you should be thrilled to have exposed. And why should one expect changing
a header file not to "break" code that includes it anyway? 

I *hate* it when people give me libraries that insist I include something in
order to include their file, or have to put includes in a certain order. It's
stupid and unnecessary if you follow the simple rule above.


jah

      [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
      [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
      [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
      [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]

John A Hughes wrote:

[snip]

> A file should contain exactly the header files it depends on, no more and
> no less. If removing a #include causes you to add it somewhere else, you
> were relying on a non-local and confusing inclusion structure anyway, which
> you should be thrilled to have exposed. And why should one expect changing
> a header file not to "break" code that includes it anyway?
> 
> I *hate* it when people give me libraries that insist I include something in
> order to include their file, or have to put includes in a certain order. It's
> stupid and unnecessary if you follow the simple rule above.

I agree. Here at Axon we also apply this concept to libraries.

Although a tool to ensure each #include is surrounded by the right 
#if's should be easy. The biggest trouble would be tracking which definition 
to use.

-- 
Andrew Dalgleish
Senior Software Engineer
Axon Research, Pty Ltd
6 Wallace Ave
Toorak, VIC
3142
AUSTRALIA
Tel:	+61-3-9826-5538
Fax:	+61-3-9824-0083
Email:	andrewd@axonet.com.au

      [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
      [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
      [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
      [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]