Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > detect necessary #includes

Reply
Thread Tools

detect necessary #includes

 
 
Steven Woody
Guest
Posts: n/a
 
      01-14-2006
hi,

after some weeks of development of a project, there likely are many
"#include" in source files which was added before but are now
unnecessary. is there any tool which can find out those "#include"s
and tell me it's safe to remove them? manual work is so time consuming.
thanks.

-
woody

 
Reply With Quote
 
 
 
 
Logan Shaw
Guest
Posts: n/a
 
      01-14-2006
Steven Woody wrote:
> hi,
>
> after some weeks of development of a project, there likely are many
> "#include" in source files which was added before but are now
> unnecessary. is there any tool which can find out those "#include"s
> and tell me it's safe to remove them? manual work is so time consuming.


Only a standards document or other API documentation can really tell
you whether it's safe to remove a #include.

Consider what happens if some documentation says this:

"foo() is available in foo.h, and bar() is available in bar.h".

Then suppose that foo.h and bar.h both contain this:

#include <foobar.h>

and that foobar.h contains the prototypes for both foo() and bar().

Now let's suppose that your code uses both foo() and bar(), and you,
by trial and error, determine you can get away by only including
foo.h, and you remove the include for bar.h. It will compile OK
right now, but what happens later on when the foobar library that
you're using changes its implementation so that foo()'s prototype
is really in foo.h and bar()'s prototype is really in bar.h? You
will have created for yourself a horrible mess because your #includes
are depending on quirks of the .h files which aren't guaranteed
rather than depending on what is guaranteed by the documentation.

More to the point, how can any automated program that just looks
at header files tell which header files are the ones that the
documentation guarantees will work?

I suppose it might be possible in some limited cases to write such
a tool, such as if no .h file every includes another .h file, but
that's not how most .h files usually work...

- Logan
 
Reply With Quote
 
 
 
 
Steven Woody
Guest
Posts: n/a
 
      01-14-2006

Logan Shaw wrote:
> Steven Woody wrote:
> > hi,
> >
> > after some weeks of development of a project, there likely are many
> > "#include" in source files which was added before but are now
> > unnecessary. is there any tool which can find out those "#include"s
> > and tell me it's safe to remove them? manual work is so time consuming.

>
> Only a standards document or other API documentation can really tell
> you whether it's safe to remove a #include.
>
> Consider what happens if some documentation says this:
>
> "foo() is available in foo.h, and bar() is available in bar.h".
>
> Then suppose that foo.h and bar.h both contain this:
>
> #include <foobar.h>
>
> and that foobar.h contains the prototypes for both foo() and bar().
>
> Now let's suppose that your code uses both foo() and bar(), and you,
> by trial and error, determine you can get away by only including
> foo.h, and you remove the include for bar.h. It will compile OK
> right now, but what happens later on when the foobar library that
> you're using changes its implementation so that foo()'s prototype
> is really in foo.h and bar()'s prototype is really in bar.h? You
> will have created for yourself a horrible mess because your #includes
> are depending on quirks of the .h files which aren't guaranteed
> rather than depending on what is guaranteed by the documentation.
>
> More to the point, how can any automated program that just looks
> at header files tell which header files are the ones that the
> documentation guarantees will work?
>
> I suppose it might be possible in some limited cases to write such
> a tool, such as if no .h file every includes another .h file, but
> that's not how most .h files usually work...
>
> - Logan


i am not going to remove any standard or system wide #includes, i am
going to remove those #includes which include my own headers.

 
Reply With Quote
 
=?ISO-8859-1?Q?Bj=F8rn_Augestad?=
Guest
Posts: n/a
 
      01-14-2006
Steven Woody wrote:
> hi,
>
> after some weeks of development of a project, there likely are many
> "#include" in source files which was added before but are now
> unnecessary. is there any tool which can find out those "#include"s
> and tell me it's safe to remove them? manual work is so time consuming.
> thanks.
>
> -
> woody
>


PC-lint(www.gimpel.com) does that, IIRC.
Bjørn
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      01-14-2006
Steven Woody said:

> hi,
>
> after some weeks of development of a project, there likely are many
> "#include" in source files which was added before but are now
> unnecessary. is there any tool which can find out those "#include"s
> and tell me it's safe to remove them? manual work is so time consuming.
> thanks.


Remove all your headers, and recompile. Then see what the compiler moans
about. This may also help you to refactor your headers in a more sensible
way.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      01-14-2006
On 13 Jan 2006 23:47:03 -0800, in comp.lang.c , "Steven Woody"
<(E-Mail Removed)> wrote:

>hi,
>
>after some weeks of development of a project, there likely are many
>"#include" in source files which was added before but are now
>unnecessary. is there any tool which can find out those "#include"s
>and tell me it's safe to remove them? manual work is so time consuming.


Well, you could us an cross-ref tool to build up a list of which
functions are used and which #include they come from, then by process
of elimination work out which ones you don't need. If you have a many
MLOC legacy project split into dozens of libs, thats how I'd do it.

However for a project you've been working on for only weeks, it would
be quicker to just comment out any header you don't think you need,
recompile and watch the warnings.
Mark McIntyre
--

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
 
Reply With Quote
 
Steven Woody
Guest
Posts: n/a
 
      01-14-2006
Richard Heathfield wrote:
> Steven Woody said:
>
> > hi,
> >
> > after some weeks of development of a project, there likely are many
> > "#include" in source files which was added before but are now
> > unnecessary. is there any tool which can find out those "#include"s
> > and tell me it's safe to remove them? manual work is so time consuming.
> > thanks.

>
> Remove all your headers, and recompile. Then see what the compiler moans
> about. This may also help you to refactor your headers in a more sensible
> way.
>


thanks for all your advices. commenting out all headers then add one by
one seems the only solution i can adapt thought i wish there exists a
more time saving method. pc-lint is not suite to me since i am working
on Linux. thanks again.

 
Reply With Quote
 
Emmanuel Delahaye
Guest
Posts: n/a
 
      01-14-2006
Steven Woody a écrit :
> after some weeks of development of a project, there likely are many
> "#include" in source files which was added before but are now
> unnecessary.


Who knows ? Things can change and the guards are doing their job. Don't
touch anything. You'll gain peanuts.

--
A+

Emmanuel Delahaye
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      01-14-2006
Steven Woody said:

> thanks for all your advices. commenting out all headers


Please, please, please don't do this. If you want to rip them out
temporarily, do it like so:

#if 0
#include "foo.h"
#include "bar.h"
#include "baz.h"
#include "quux.h"
#endif

Then, as you discover you need them, fish them out of the #if and into the
code proper.

Comment syntax is for adding something extra to the code, not for taking
something away.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
 
Reply With Quote
 
Steven Woody
Guest
Posts: n/a
 
      01-14-2006

Richard Heathfield wrote:
> Steven Woody said:
>
> > thanks for all your advices. commenting out all headers

>
> Please, please, please don't do this. If you want to rip them out
> temporarily, do it like so:
>
> #if 0
> #include "foo.h"
> #include "bar.h"
> #include "baz.h"
> #include "quux.h"
> #endif


i've not seen big difference between this method and that of commting.

>
> Then, as you discover you need them, fish them out of the #if and into the
> code proper.
>
> Comment syntax is for adding something extra to the code, not for taking
> something away.


how to understand this ? i am so interesting

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
is a digital filter necessary? nesppi@gmail.com VHDL 1 01-13-2006 11:37 AM
Book is necessary to pass OCP certification. Oneil Microsoft Certification 0 11-27-2005 07:20 AM
cookie handling - is there a list of *necessary* cookies ?? cookie-monster Firefox 1 03-05-2005 03:40 AM
Is an access-group command necessary for ACLs? ed@novani.com Cisco 4 12-30-2004 05:27 PM
ORM resources necessary for 70-300 TomTom MCSD 7 08-17-2004 07:08 AM



Advertisments