Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

detect necessary #includes

 
 
Emmanuel Delahaye
Guest
Posts: n/a
 
      01-14-2006
Richard Heathfield a écrit :
> #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.


"fish them out"

I like it !

--
A+

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

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


The obvious difference is that "commenting out" code is an abuse of the
syntax. But perhaps you're not so interested in clarity, and want a more
practical motivation. Okay, here it is:

foo(); /* do the foo thing */
if(condition) /* we only want to bar if there's an 'r' in the month */
{
bar(); /* this will use the default directory, C:\bar\ */
baz(); /* don't forget to baz everything back to normal */
}

Observe the problem with "commenting out" this code:

/*
foo(); /* do the foo thing */
if(condition) /* we only want to bar if there's an 'r' in the month */
{
bar(); /* this will use the default directory, C:\bar\ */
baz(); /* don't forget to baz everything back to normal */
}
*/

See the difficulty? Only the foo() call has been "commented out". And now
you have a syntax error on the last line - "unmatched closing comment" or
similar.

Now let's do it properly:

#if 0
foo(); /* do the foo thing */
if(condition) /* we only want to bar if there's an 'r' in the month */
{
bar(); /* this will use the default directory, C:\bar\ */
baz(); /* don't forget to baz everything back to normal */
}
#endif

No syntax error. No problem with existing comments. And to undo it, you need
only change a single character (change 0 to 1) - and of course it's just as
easy to re-do it.

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


Unmatched closing comment.

--
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
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      01-14-2006
Mark McIntyre <(E-Mail Removed)> writes:
> On 13 Jan 2006 23:47:03 -0800, in comp.lang.c , "Steven Woody"
> <(E-Mail Removed)> wrote:
>>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.


The cross-ref tool would only tell you about headers that provide
function declarations.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-14-2006
Richard Heathfield <(E-Mail Removed)> writes:
> 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.


Uncomfortable as it is to disagree with Richard, I have to say I don't
think this is a big deal. Commenting out substantial blocks of code
is a bad idea, partly because comments don't nest, but I don't see a
problem with commenting out #include directives one at a time:

/* #include "foo.h" */
/* #include "bar.h" */
/* #include "baz.h" */
/* #include "quux.h" */

With the "#if 0", re-adding "bar.h" results in:

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

as opposed to:

/* #include "foo.h" */
#include "bar.h"
/* #include "baz.h" */
/* #include "quux.h" */

which makes it much easier to tell at a glance which lines are active
and which ones aren't.

Furthermore, the whole idea any #includes that are commented out will
eventually be removed altogether, so the comments are only temporary.

There is a risk if you have comments on the #include lines, but then
you just have to be careful to comment out only the directive, not the
entire line.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      01-14-2006
Keith Thompson said:

> Uncomfortable as it is to disagree with Richard,


That should tell you something right there.

> I have to say I don't
> think this is a big deal. Commenting out substantial blocks of code
> is a bad idea, partly because comments don't nest, but I don't see a
> problem with commenting out #include directives one at a time:
>
> /* #include "foo.h" */
> /* #include "bar.h" */
> /* #include "baz.h" */
> /* #include "quux.h" */
>
> With the "#if 0", re-adding "bar.h" results in:
>
> #if 0
> #include "foo.h"
> #endif
> #include "bar.h"
> #if 0
> #include "baz.h"
> #include "quux.h"
> #endif


Huh? What are you talking about?

Before:

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

Edit:

/bar
dd2jp

After:

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

The quickest way I can find to remove the comments you used is:

/bar
03x$2Xx

which is actually slightly more work.

--
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 Sat, 14 Jan 2006 13:44:20 +0000 (UTC), in comp.lang.c , Richard
Heathfield <(E-Mail Removed)> wrote:

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


(example using #if 0)
what advantage does this have over

//#include "foo.h"
//#include "bar.h"

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


Dubious. Commenting out is extremely useful during debugging. When it
comes to prod, he will presumably delete the lines entirely anyway.
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
 
Mark McIntyre
Guest
Posts: n/a
 
      01-14-2006
On 14 Jan 2006 07:28:57 -0800, in comp.lang.c , "Steven Woody"
<(E-Mail Removed)> wrote:

>
>Richard Heathfield wrote:
>>
>> Comment syntax is for adding something extra to the code, not for taking
>> something away.

>
>how to understand this ? i am so interesting


Richard means that when your code is production ready, the only
commented areas should be actual comments - there should be no code
blocks commented out.

I almost agree with this. If there were a simple single-line macro way
to hide a line from the compiler, I'd agree entirely. As it is
however, the C++ // comment is very useful for commenting out debug
that you want to retain but not use all the time.
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
 
Mark McIntyre
Guest
Posts: n/a
 
      01-14-2006
On Sat, 14 Jan 2006 17:00:43 +0000 (UTC), in comp.lang.c , Richard
Heathfield <(E-Mail Removed)> wrote:

(snip example of nested comments)

>See the difficulty? Only the foo() call has been "commented out".


You can do anything if you're careless.
Commenting out entire code blocks like that is indeed a bad idea.

On the other hand, im my opinion
foo();
//printf("msg I don't need when in prod\n");
bar();

is pretty useful.

Its no big deal though.
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
 
Mark McIntyre
Guest
Posts: n/a
 
      01-14-2006
On Sat, 14 Jan 2006 21:23:21 +0000 (UTC), in comp.lang.c , Richard
Heathfield <(E-Mail Removed)> wrote:

>Huh? What are you talking about?
>
>#if 0
>#include "foo.h"
>#include "baz.h"
>#include "quux.h"
>#endif
>#include "bar.h"


What if bar requires baz but not foo or quux ? More gratuitous entries
in cvs....

>which is actually slightly more work.


Feel the power of the dark side, Anakin. The // comment is your ally.


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
 
Mark McIntyre
Guest
Posts: n/a
 
      01-14-2006
On Sat, 14 Jan 2006 19:32:35 GMT, in comp.lang.c , Keith Thompson
<(E-Mail Removed)> wrote:

>Mark McIntyre <(E-Mail Removed)> writes:
>
>> 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.

>
>The cross-ref tool would only tell you about headers that provide
>function declarations.


You're right , you'd need to be careful that you understood how the
tool worked. That said, I've used a tool that completely x-ref'ed a
module to the extent of listing all objects and their origins. From
that it would be pretty simple to parse out all unused headers in each
source module.

It'd probably still be quicker to use the comment-out approach tho!



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