detect necessary #includes

[Richard Heathfield]

Mark McIntyre said:

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

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

It doesn't generate a syntax error diagnostic message in a C90 compiler. I
don't know about you, but personally I consider that a distinct advantage.

 

[Richard Heathfield]

Mark McIntyre said:

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

is pretty useful.

If only it compiled; and if only there weren't that line-splicing gotcha for
BCPL-style comments ending in \

 

[Keith Thompson]

Mark McIntyre said:

It doesn't generate a syntax error diagnostic message in a C90 compiler. I
don't know about you, but personally I consider that a distinct advantage.

Many pre-C99 compilers support // comments as an extension. Since the
comments in question are purely temporary, there's little point in not
using them if they happen to be available.

 

[Chuck F.]

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.

There is a Unix/Linux version available, in shrouded source form,
which will cost you about 1000 USDOL. It is probably cheaper to
buy PClint and a minimal windoze box.

There is also opensource splint.

You can always run an xref on the various .h files, so that the
defining header for each variable is identified. Then collect the
compiler moans after commenting out the headers, sort them by
'missing prototype' and 'undefined' or equivalent, and look those
up in the cross-reference. This would be suitable for a large project.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[Chuck F.]

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

For example, the original was:

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

and comments don't nest.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[Chuck F.]

.... snip ...

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

is pretty useful.

Except that when I compile it with gcc -ansi -pedantic I get syntax
errors! What could possibly be wrong?

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[Chuck F.]

Steven Woody a écrit :


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

On the contrary, getting rid of that dead wood may well save
man-years of future maintenance programming time. If the project
is screwed up with all that stuff, do you think that scope has been
properly minimized? One should try to leave things a little better
than one found them.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[Mark L Pappin]

What if bar requires baz but not foo or quux ?

Then you'll either know that aahead of time and rearrange them
together, or you'll discover it when a compile fails and _then_
rearrange them.

More gratuitous entries in cvs....

[OT]
Committing known-temporary changes during an investigative phase
certainly does produce gratuitous CVS entries.

Edit - Commit - Compile with errors
Edit - Commit - Compile - Test
Edit to clean up - Commit

Or perhaps you're saying that you _know_ the first two Commits here
are gratuitous, but that re-ordering lines is _more_ gratuitous? If
your CVS stores deltas as 'ed' scripts, then (as Richard shows else-
thread) his way is actually smaller and thus _less_ gratuitous.
[/OT]

mlp

 

[Logan Shaw]

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.

This is the type of thing that can easily be done with a Perl script or
something. Recognizing includes can be done with

/^\s+\#\s+include/

and you can check the return code of the compiler to figure out whether
the compile failed. From there you can generate a list of which line
numbers of which files can be removed without generating a compile
error (or generate marked up C files), and manually go through and
think about which ones are actually safe to remove. That should save
time since you've eliminated a huge number of ones that are KNOWN
to be unsafe to remove.

- Logan

 

[Charles Richmond]

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.

Yes, *real* work is so tedious and time consuming. After all, you
*have* a computer to do all that... ;-)

 

[Richard Heathfield]

Keith Thompson said:

Many pre-C99 compilers support // comments as an extension.

I ought to write an essay on this subject, so that I can simply post a URL.

Look, yes, *of course* it's offered as an extension in, as you say, many
pre-C99 implementations. But there are times - and for me, it's most of the
time - when you want the code to be as portable as possible, so you crank
your warning level up to the highest possible point, and then you might not
be able to configure warnings individually (depending on your compiler),
and so you live with the lack of this particular extension (which, for me,
is no great loss) for the sake of the extra diagnostics you get elsecode.

 

[Mark L Pappin]

For example, the original was:

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

and comments don't nest.

Although you can take advantage of this (I seem to recall the
configuration options in the Nethack source do) thus:

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

2 extra chars per temporarily-removed #include, rather than 13 chars
per block; of course, it only works if there _is_ such a comment after
each one, but you could add one while you're there.

(Yes, I know // comments cost the same nuber of extra chars and don't
depend on the presence of a 'regular' comment - // is not your friend
unless and until every compiler you might possibly be using this
technique on is guaranteed to support them.)

mlp

 

[Mark McIntyre]

It doesn't generate a syntax error diagnostic message in a C90 compiler. I
don't know about you, but personally I consider that a distinct advantage.

I can't help it if you're stuck with fifteen-year-old technology

Seriously tho, I can't think of a single compiler I've used since the
mid nineties that didn't support C++ style commenting. Sure, its not
100% ISO C, but I still consider it a bogus argument.

Mark McIntyre

 

[Mark McIntyre]

Mark McIntyre said:


If only it compiled; and if only there weren't that line-splicing gotcha for
BCPL-style comments ending in \

I already said, you can do anything if you're careless.

A foolish inconsistency is the hobgoblin of small minds...

Mark McIntyre

 

[Mark McIntyre]

Keith Thompson said:


time - when you want the code to be as portable as possible, so you crank
your warning level up to the highest possible point, and then you might not
be able to configure warnings individually (depending on your compiler),

Thats fine, but in that case I'd suggest avoiding sweeping
generalizations of the type you made earlier in this thread, or at
least prefix it with some explanatory text along the lines of "I use
this method, because I'm stuck with barbaric pre-stone-age compilers".
On this sbuject I should know, as I've been roasted often enough for
doing the same myself....

Mark McIntyre

 

[Mark McIntyre]

Except that when I compile it with gcc -ansi -pedantic I get syntax
errors! What could possibly be wrong?

Do you often find your employers require those settings in official
builds?

Mark McIntyre

 

[Steven Woody]

Steven Woody said:


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.

thanks!

 

[Chuck F.]

Do you often find your employers require those settings in official
builds?

*I* require it in builds of anything except system dependent
interface modules. These should be a small portion of any major
system.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[Chuck F.]

.... snip ...

Seriously tho, I can't think of a single compiler I've used since the
mid nineties that didn't support C++ style commenting. Sure, its not
100% ISO C, but I still consider it a bogus argument.

As Richard pointed out elsethread, once you turn up the diagnostic
level to catch as many errors as possible, you have probably
disabled any ability to use // comments. Around here we aim for
maximum portability. // comments are not conducive to such.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[Richard Heathfield]

Mark McIntyre said:

I can't help it if you're stuck with fifteen-year-old technology

I can download the latest gcc just as easily as you can. That's not the
issue. What I'm stuck with is a requirement for portability that,
presumably, exceeds yours.

Seriously tho, I can't think of a single compiler I've used since the
mid nineties that didn't support C++ style commenting. Sure, its not
100% ISO C, but I still consider it a bogus argument.

You *still* miss the point, which is that turning off syntax error
diagnostics for // can, in some implementations, also turn off a whole
bunch of other diagnostics that I for one would rather not lose.