detect necessary #includes

[Steven Woody]

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

[Logan Shaw]

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

[Steven Woody]

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.

[Bjørn Augestad]

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

[Richard Heathfield]

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)

[Mark McIntyre]

On 13 Jan 2006 23:47:03 -0800, in comp.lang.c , "Steven Woody"
<na********@gmail.com> 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 =----

[Steven Woody]

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.

[Emmanuel Delahaye]

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

[Richard Heathfield]

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)

[Steven Woody]

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

[Emmanuel Delahaye]

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

[Richard Heathfield]

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)

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.net> writes:

On 13 Jan 2006 23:47:03 -0800, in comp.lang.c , "Steven Woody"
<na********@gmail.com> 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) ks***@mib.org <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.

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalid> 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) ks***@mib.org <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.

[Richard Heathfield]

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)

[Mark McIntyre]

On Sat, 14 Jan 2006 13:44:20 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> 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 =----

[Mark McIntyre]

On 14 Jan 2006 07:28:57 -0800, in comp.lang.c , "Steven Woody"
<na********@gmail.com> 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 =----

[Mark McIntyre]

On Sat, 14 Jan 2006 17:00:43 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> 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 =----

[Mark McIntyre]

On Sat, 14 Jan 2006 21:23:21 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> 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 =----

[Mark McIntyre]

On Sat, 14 Jan 2006 19:32:35 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

Mark McIntyre <ma**********@spamcop.net> 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 =----

[Richard Heathfield]

Mark McIntyre said:

On Sat, 14 Jan 2006 13:44:20 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> 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"

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
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

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

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

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalid> writes:

Mark McIntyre said:

On Sat, 14 Jan 2006 13:44:20 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> 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"

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.

[Mark L Pappin]

Mark McIntyre <ma**********@spamcop.net> writes:

Richard Heathfield <in*****@invalid.invalid> wrote:

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

[Chuck F.]

Steven Woody wrote:

Richard Heathfield wrote:

Steven Woody said:

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.

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

Steven Woody wrote:

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.

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

Mark McIntyre wrote:

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

Emmanuel Delahaye wrote:

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.

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

[Logan Shaw]

Steven Woody wrote:

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]

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.

Yes, *real* work is so tedious and time consuming. After all, you
*have* a computer to do all that... ;-)
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+

[Richard Heathfield]

Keith Thompson said:

Richard Heathfield <in*****@invalid.invalid> writes:

Mark McIntyre said:

On Sat, 14 Jan 2006 13:44:20 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> 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"

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.

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.

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

[Mark L Pappin]

"Chuck F. " <cb********@yahoo.com> writes:

Steven Woody wrote:

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.

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]

On Sun, 15 Jan 2006 00:05:06 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

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

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

[Mark McIntyre]

On Sun, 15 Jan 2006 00:08:24 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

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 \

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

A foolish inconsistency is the hobgoblin of small minds... :-)

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

[Mark McIntyre]

On Sun, 15 Jan 2006 07:00:30 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

Keith Thompson said:

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

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

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

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

[Mark McIntyre]

On Sat, 14 Jan 2006 22:42:43 -0500, in comp.lang.c , "Chuck F. "
<cb********@yahoo.com> wrote:

Mark McIntyre wrote:

... 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? :-)

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

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

[Steven Woody]

Richard Heathfield wrote:

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.

thanks!

[Chuck F.]

Mark McIntyre wrote:

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

[Chuck F.]

Mark McIntyre wrote:

"Chuck F. " <cb********@yahoo.com> wrote:

Mark McIntyre wrote:

... 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? :-)

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

[Richard Heathfield]

Mark McIntyre said:

On Sun, 15 Jan 2006 00:05:06 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

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

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.

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

[Richard Heathfield]

Mark McIntyre said:

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

A foolish inconsistency is the hobgoblin of small minds... :-)

Was the misquotation deliberate?

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

[Richard Heathfield]

Mark McIntyre said:

"Chuck F. " wrote:

Mark McIntyre wrote:

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? :-)

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

Absolutely. You mean yours don't? Sheesh, sucks to be you. It's much easier
to insist on decent diagnostic checking when your project lead insists on
it as well.

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

[Mark McIntyre]

On Sun, 15 Jan 2006 08:14:40 -0500, in comp.lang.c , "Chuck F. "
<cb********@yahoo.com> wrote:

Mark McIntyre wrote:

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

We could argue this all day. For what its worth, any decent compiler
will come with the ability to disable warnings you don't mind about.
But frankly, I'm not all that hung up on either method. I'd use the
macro method for large commentings out, the comment method for small
ones. YMMV. FIDGTW.... :-)

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

[Mark McIntyre]

On Sun, 15 Jan 2006 20:27:17 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

You *still* miss the point,

I ___NEVER__ missed the point. You on the other hand are being
clinically dense^wpedantic today.
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.

Then get a decent implementation. Don't blame me for the shortcoming
of your toolset.
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 =----

[Mark McIntyre]

On Sun, 15 Jan 2006 20:28:02 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

Mark McIntyre said:

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

A foolish inconsistency is the hobgoblin of small minds... :-)

Was the misquotation deliberate?

Was there one? I rest my case.
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 =----

[Mark McIntyre]

On Sun, 15 Jan 2006 20:30:10 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

Mark McIntyre said:

"Chuck F. " wrote:

Mark McIntyre wrote:
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? :-)
Do you often find your employers require those settings in official
builds? :-)

Absolutely. You mean yours don't?

Certainly not - how on earth would you compile several million lines
of Open Interface, DBlib and misc assembler with those warning levels.Sheesh, sucks to be you. It's much easier
to insist on decent diagnostic checking when your project lead insists on
it as well.

You live in cloud cuckoo land.
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 =----

[Mark McIntyre]

On Sun, 15 Jan 2006 20:30:10 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

(of compiling with gcc's strict ANSI flags)

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

Absolutely.

I meant to add: I'm sorry, but now you're being disingenuous, and
quite possibly mendacious. Please do take offense at that if it
offends you, but this discussion has descended into idiocy, so idiotic
replies are called for.

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

[Mark McIntyre]

On Sun, 15 Jan 2006 20:27:17 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

Mark McIntyre said:

On Sun, 15 Jan 2006 00:05:06 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

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

I can download the latest gcc just as easily as you can.

Then do so, and (sorry about this) learn to use it properly.

thats enough about this.
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 =----

[Richard Heathfield]

Mark McIntyre said:

On Sun, 15 Jan 2006 20:27:17 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

You *still* miss the point,

I ___NEVER__ missed the point. You on the other hand are being
clinically dense^wpedantic today.

No comment.

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.

Then get a decent implementation. Don't blame me for the shortcoming
of your toolset.

You **still** miss the point. I don't write code for an implementation. I
write C code. Quite often, I don't have any control whatsoever over which
implementation (or implementationS) will be used to compile the code. So I
have to write in a portable way. The // "comment" syntax, quite simply, is
not portable.

If I were only writing for my "favourite" implementation, this would be so
not an issue as to be a complete irrelevance, but so would any number of
other non-portable constructs, such as void main, behaviour on signed
integer overflow, forgetting stdio.h for printf, and so on and so forth.
And I'd be cheerfully using sockets and threads and console I/O and all
manner of other language extensions, without worrying one jot about whether
J Random Conforming Implementation supported them. Are you suggesting that
we should be recommending such constructs here on comp.lang.c?

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

[Richard Heathfield]

Mark McIntyre said:

You live in cloud cuckoo land.

Consider other possibilities.

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