Lisp- (;) or BASIC- (REM) like comments in C?
Tomoyuki Tanaka
do recent C compilers have
Lisp- (;) or BASIC- (REM) like comments,
instead of the standard /* */ ?
--------------------------------------------------------------------
In article <35239046....@nntp.service.ohio-state.edu>,
Brent Worden <brent....@poboxe.com> wrote:
>>
>>is there a good shareware C compiler for IBM PC / DOS?
>>
>Try the GNU C compiler for DOS. It's free.
>http://www.delorie.com/djgpp/
>
thanks!
Dann Corbit
Tomoyuki Tanaka wrote in message <6g0trb$40q$1...@mark.ucdavis.edu>...
>
>do recent C compilers have
>Lisp- (;) or BASIC- (REM) like comments,
>instead of the standard /* */ ?
If they provide these things, then they are not acting as C compilers, since
that would be a clear violation of the language. A semicolon (;) is a
statement separator in C. And the token REM is clearly an allowed
identifier. And you're one day late.
--
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ ftp: ftp://rtfm.mit.edu, C-FAQ Book: ISBN 0-201-84519-9
Try "C Programming: A Modern Approach" ISBN 0-393-96945-2
Want Software? Algorithms? Pubs? http://www.infoseek.com
Jedidiah Whitten
Not as far as I know, but you could get a C++ compiler to compile your C
code, and then use the // comments.
Tomoyuki Tanaka (ez07...@dilbert.ucdavis.edu) wrote:
:
: do recent C compilers have
: Lisp- (;) or BASIC- (REM) like comments,
: instead of the standard /* */ ?
:
:
:
: --------------------------------------------------------------------
: In article <35239046....@nntp.service.ohio-state.edu>,
: Brent Worden <brent....@poboxe.com> wrote:
: >>
: >>is there a good shareware C compiler for IBM PC / DOS?
: >>
: >Try the GNU C compiler for DOS. It's free.
: >http://www.delorie.com/djgpp/
: >
: thanks!
:
--
Jedidiah Whitten (jswh...@ucdavis.edu)
+------------------------------------------+
| University of California, Davis |
| http://wwwcsif.cs.ucdavis.edu/~whitten |
| http://wwp.mirabilis.com/6569964 |
+------------------------------------------+
Tomoyuki Tanaka
In article <6g103e$ql9$1...@client2.news.psi.net>,
Dann Corbit <dco...@solutionsiq.com> wrote:
>>
>>do recent C compilers have
>>Lisp- (;) or BASIC- (REM) like comments,
>
>If they provide these things, then they are not acting as C compilers, since
>that would be a clear violation of the language. A semicolon (;) is a
>statement separator in C. And the token REM is clearly an allowed
>identifier. And you're one day late.
hi. thanks. (i'm one day late?)
i think it's good to have both kinds of comments.
Common Lisp has both!
>Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
>C-FAQ ftp: ftp://rtfm.mit.edu, C-FAQ Book: ISBN 0-201-84519-9
>Try "C Programming: A Modern Approach" ISBN 0-393-96945-2
did you write these things?
--
;;; TANAKA Tomoyuki ("Mr. Tanaka" or "Tomoyuki")
;;; http://www.cs.indiana.edu/hyplan/tanaka.html
Martin Ambuhl
Tomoyuki Tanaka wrote in message <6g0trb$40q$1...@mark.ucdavis.edu>...
|
|do recent C compilers have
|Lisp- (;) or BASIC- (REM) like comments,
|instead of the standard /* */ ?
Not any that conform to ANSI/ISO 9899-1990
Dann Corbit
Tomoyuki Tanaka wrote in message <6g18c0$c6p$1...@mark.ucdavis.edu>...
>>>Lisp- (;) or BASIC- (REM) like comments,
>>
>>If they provide these things, then they are not acting as C compilers,
since
>>that would be a clear violation of the language. A semicolon (;) is a
>>statement separator in C. And the token REM is clearly an allowed
>>identifier. And you're one day late.
>
>hi. thanks. (i'm one day late?)
from.
>i think it's good to have both kinds of comments.
>Common Lisp has both!
Alright, but any more suggestions about putting them into C and I'm going to
start with some ugly parenthesis jokes about your special love.
>>Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
>>C-FAQ ftp: ftp://rtfm.mit.edu, C-FAQ Book: ISBN 0-201-84519-9
>>Try "C Programming: A Modern Approach" ISBN 0-393-96945-2
>
>did you write these things?
I WISH! They are just recommendations of things that I found useful.
--
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ ftp: ftp://rtfm.mit.edu, C-FAQ Book: ISBN 0-201-84519-9
Try "C Programming: A Modern Approach" ISBN 0-393-96945-2
firewind
On 2 Apr 1998, Tomoyuki Tanaka wrote:
> do recent C compilers have
> Lisp- (;) or BASIC- (REM) like comments,
> instead of the standard /* */ ?
Of course not! Why would they? (And -how- would they, given the role that
the semicolon plays in the C grammar?)
--
(initiator of the campaign for grumpiness where grumpiness is due in c.l.c)
Attempting to write in a hybrid which can be compiled by either a C compiler
or a C++ compiler produces a compromise language which combines the drawbacks
of both with the advantages of neither.
-- John Winters <jo...@polo.demon.co.uk> in comp.lang.c
Joshua Waxman
On 3 Apr 1998, Tomoyuki Tanaka wrote:
> In article <Pine.LNX.3.95.98040...@metroid.dyn.ml.org>,
> firewind <fire...@metroid.dyn.ml.org> wrote:
> >
> >> do recent C compilers have
> >> Lisp- (;) or BASIC- (REM) like comments,
> >> instead of the standard /* */ ?
> >
> >Of course not! Why would they? (And -how- would they, given the role that
> >the semicolon plays in the C grammar?)
>
>
> by choosing a comment character other than the semicolon.
>
>
Someone will correct me if I am wrong, but I seem to recall that C9X
intends to support // comments. If so, that might be a useful answer to
the original poster. In other words, currently, no, there are no single
line comments in C as there is in BASIC. However, in the future there may
be. Also, if you have access to a C++ compiler instead of a C compiler
(some people do not recognize the distinction between these two
languages), then // will REM the remainder of the line.
Hope this helps.
Josh Waxman
firewind
On 2 Apr 1998, Jedidiah Whitten wrote:
> Not as far as I know, but you could get a C++ compiler to compile your C
> code, and then use the // comments.
False. (Come on, guys, April Fools' Day is -over-.) It is a trivial task
to create conforming C code that will not compile with a C++ compiler. Your
suggestion is akin to saying that he should use 'REM' and 'compile' with a
BASIC compiler (assuming such a beast exists).
firewind
On 2 Apr 1998, Tomoyuki Tanaka wrote:
> Dann Corbit <dco...@solutionsiq.com> wrote:
> >If they provide these things, then they are not acting as C compilers, since
> >that would be a clear violation of the language. A semicolon (;) is a
> >statement separator in C. And the token REM is clearly an allowed
> >identifier. And you're one day late.
>
> i think it's good to have both kinds of comments.
Can you explain what you mean by 'both kinds'? Perhaps you mean a comment
that is terminated by a newline?
> >Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> >C-FAQ ftp: ftp://rtfm.mit.edu, C-FAQ Book: ISBN 0-201-84519-9
> >Try "C Programming: A Modern Approach" ISBN 0-393-96945-2
>
> did you write these things?
No, he didn't. Read them.
Joshua Waxman
On 3 Apr 1998, Tomoyuki Tanaka wrote:
> In article <Pine.LNX.3.95.98040...@metroid.dyn.ml.org>,
> firewind <fire...@metroid.dyn.ml.org> wrote:
> >
> >>
> >> i think it's good to have both kinds of comments.
> >
> >Can you explain what you mean by 'both kinds'? Perhaps you mean a comment
> >that is terminated by a newline?
> >
There are some drawbacks to this method, but how about:
#define COMMENT this is a comment
#define COMMENT and so is this
If you do this, do not use COMMENT as an identifier. Also this will have
problems if you terminate with a backslash. But then again, I read
somewhere that some compilers have this problem with C++'s // comments.
Josh Waxman
firewind
On 3 Apr 1998, Tomoyuki Tanaka wrote:
> firewind <fire...@metroid.dyn.ml.org> wrote:
> >Can you explain what you mean by 'both kinds'? Perhaps you mean a comment
> >that is terminated by a newline?
>
> that's right.
I see.
> Common Lisp has both kinds.
So does (will, actually) C.
Tomoyuki Tanaka
In article <Pine.LNX.3.95.98040...@metroid.dyn.ml.org>,
firewind <fire...@metroid.dyn.ml.org> wrote:
>
>> Lisp- (;) or BASIC- (REM) like comments,
>> instead of the standard /* */ ?
>
>Of course not! Why would they? (And -how- would they, given the role that
>the semicolon plays in the C grammar?)
by choosing a comment character other than the semicolon.
--------------------------------------------------------------------
please do not call me "Tanaka-san" in English text.
white American comedians often use the "-san" ending to ridicule
the Japanese and Japanese Americans.
Exil Q Trob
On 2 Apr 1998, Tomoyuki Tanaka wrote:
>
> do recent C compilers have
> Lisp- (;) or BASIC- (REM) like comments,
> instead of the standard /* */ ?
I believe you are looking for a comment form that extends to the end of the
line, instead of requiring/allowing explicit termination.
C++ allows comments of this sort to begin with '//'. This is not an official
part of C, but you may find that your compiler supports it as a non-portable
extension to the language.
David G
Tomoyuki Tanaka
In article <Pine.LNX.3.95.98040...@metroid.dyn.ml.org>,
firewind <fire...@metroid.dyn.ml.org> wrote:
>
>>
>
>that is terminated by a newline?
>
that's right.
Common Lisp has both kinds.
what is more, the paired kind (/* */ in C, #| |# (?) in Common
Lisp) can nest in Common Lisp.
Mark Brown
ez07...@dilbert.ucdavis.edu (Tomoyuki Tanaka) writes:
> do recent C compilers have
> Lisp- (;) or BASIC- (REM) like comments,
> instead of the standard /* */ ?
Not yet. Many compilers support C++ // comments, but not in
conforming mode (where such comments are a syntax error). These
comments are going to be introduced in the next revision of the C
standard, but for now all there is is /* */.
--
Mark Brown mailto:bro...@tardis.ed.ac.uk (Trying to avoid grumpiness)
http://www.tardis.ed.ac.uk/~broonie/
EUFS http://www.ed.ac.uk/~filmsoc/
Jos A. Horsmeier
Tomoyuki Tanaka wrote:
> do recent C compilers have
> Lisp- (;) or BASIC- (REM) like comments,
> instead of the standard /* */ ?
char* answer= 1//* mayhap */42
?"no":"yes";
kind regards,
Jos aka j...@and.nl
Tom Watson
In article <6g1crj$fsl$1...@mark.ucdavis.edu>, ez07...@dilbert.ucdavis.edu
(Tomoyuki Tanaka) wrote:
> In article <Pine.LNX.3.95.98040...@metroid.dyn.ml.org>,
> firewind <fire...@metroid.dyn.ml.org> wrote:
> >
> >> do recent C compilers have
> >> Lisp- (;) or BASIC- (REM) like comments,
> >> instead of the standard /* */ ?
> >
> >Of course not! Why would they? (And -how- would they, given the role that
> >the semicolon plays in the C grammar?)
>
>
> by choosing a comment character other than the semicolon.
>
Sorry, all taken. Well, most all taken. The only ones really not taken
are the '@' character and the '`' character. In some PCC derived
compilers, the '`' character was used to make up GCOS constants. The
compiler informed you of this and errored out your program.
As said in other posts. This question is a day late.
--
t...@cagent.com (Home: t...@johana.com)
Please forward spam to: anna...@hr.house.gov (my Congressman), I do.
fungus
Karl Stenerud wrote:
>
> It seems that after all of the idiotic posts, homework posts, and
> trolls in the recent past, a certain arrogance has developed in
> this newsgroup...
>
Is c.l.c bashing flavour of the month or something?
As far as I'm concerned you can take your pathetic complaints and
stick them in your output port. Arrogance indeed...pah!
--
<\___/>
/ O O \ My web site: http://artlum.com/
\_____/ FTB. To e-mail me use: ftb@the_above_domain.com
roland_hughes
In <6g0trb$40q$1...@mark.ucdavis.edu>, on 04/02/98
>--------------------------------------------------------------------
>In article <35239046....@nntp.service.ohio-state.edu>, Brent Worden
><brent....@poboxe.com> wrote:
>>>
>>>is there a good shareware C compiler for IBM PC / DOS?
>>>
>>Try the GNU C compiler for DOS. It's free.
>>http://www.delorie.com/djgpp/
>>
>thanks!
No they have c++ comments
//
--
-----------------------------------------------------------
yyy...@ibm.net
-----------------------------------------------------------
firewind
On Sat, 4 Apr 1998, it was written:
> > Brent Worden <brent....@poboxe.com> wrote:
> >>Try the GNU C compiler for DOS. It's free.
> >>http://www.delorie.com/djgpp/
>
> No they have c++ comments
This is why gcc should always be invoked with the switches '-Wall -ansi
-pedantic' to make sure such extensions get turned off.
Kaz Kylheku
In article <6g0trb$40q$1...@mark.ucdavis.edu>,
Tomoyuki Tanaka <ez07...@dilbert.ucdavis.edu> wrote:
>
>do recent C compilers have
>Lisp- (;) or BASIC- (REM) like comments,
>instead of the standard /* */ ?
Do recent English speakers support French- (ne pas) like negation?
Get real.
Lawrence Kirby
In article <6g1fui$iqt$1...@mark.ucdavis.edu>
ez07...@dilbert.ucdavis.edu "Tomoyuki Tanaka" writes:
>In article <Pine.LNX.3.95.98040...@metroid.dyn.ml.org>,
>firewind <fire...@metroid.dyn.ml.org> wrote:
>>
>>>
>>> i think it's good to have both kinds of comments.
>>
>>Can you explain what you mean by 'both kinds'? Perhaps you mean a comment
>>that is terminated by a newline?
>>
>
>that's right.
>Common Lisp has both kinds.
It appears the the next revision of the C language (dubbed C9X) will have
both kinds.
>what is more, the paired kind (/* */ in C, #| |# (?) in Common
>Lisp) can nest in Common Lisp.
That's unfortunate (well maybe it is OK in a LISP context). Luckily they
don't in C (and won't in C9X either).
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Rolf Magnus
Lawrence Kirby wrote:
> >what is more, the paired kind (/* */ in C, #| |# (?) in Common
> >Lisp) can nest in Common Lisp.
>
> That's unfortunate (well maybe it is OK in a LISP context). Luckily they
> don't in C (and won't in C9X either).
What is so bad about nesting comments in C? I can't find any
disadvantage.
I use nested comments sometimes, but my watcom c gives me a warning for
every one it finds in my code...
Perique des Palottes
Rolf Magnus wrote:
> What is so bad about nesting comments in C? I can't find any
> disadvantage.
No need to. Use:
#if 0
...
#endif
as many times as you please to nest and renest ad infinitum.
> I use nested comments sometimes, but my watcom c gives me a
> warning for every one it finds in my code...
Saying that is like saying that you like a lot to blow your head
against the wall for the pleasure that comes from stopping to blow.
Good luck.
--
"La esperanza es lo ultimo que se pierde. Y es un pena,
porque si se perdiera lo primero, quiza se hiciera algo
para solucionar las cosas." - J. Perich
Peter Seebach
In article <nBzV.363$hQ3.8...@newsgate.direct.ca>,
ne joke pas. It could happen, and indeed, a lot of people I know use
it. Of course, we invent jargon and slang all over - in English. It's
a bad idea to try to use lang with a compiler.
Formal methods for formal systems.
-s
--
Copyright '98, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Not speaking for my employer. Questions on C/Unix? Send mail for help.
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
Karl Stenerud
Tomoyuki Tanaka <ez07...@dilbert.ucdavis.edu> wrote in article
<6g0trb$40q$1...@mark.ucdavis.edu>...
>
> do recent C compilers have
> Lisp- (;) or BASIC- (REM) like comments,
> instead of the standard /* */ ?
Nope. ANSI C only uses /* */ comments.
Some compilers let you use the C++ style // comment, which is more like
lisp's ; and basic's REM, but it's not standard and therefore not
guaranteed to work on any given ANSI C compiler.
It's interesting seeing the flames-a-plenty flowing from this topic for
what is, after all, a legitimate question about C from someone who would
like to know.\
It seems that after all of the idiotic posts, homework posts, and trolls in
the recent past, a certain arrogance has developed in this newsgroup...
Or is it just me? =)
Dann Corbit
Karl Stenerud wrote in message <01bd6185$f58942c0$7e13...@bm.mdsi.bc.ca>...
[snip]
>It seems that after all of the idiotic posts, homework posts, and trolls in
>the recent past, a certain arrogance has developed in this newsgroup...
>
>Or is it just me? =)
Well, the April 1 posts were rather explainable. I think the question was
answered in other branches of the thread and fairly. Clearly, there are
some arrogant posts from time to time. I think, however, that the arrogance
is mostly in the eye of the beholder; especially in the eye of ignorant,
insufferable, moronic louts like you! And how dare you even suggest such a
thing! It makes me whinge. By the way, anyone know what happened to Mr.
Winters? I'm about ready to go into mourning at another tragic loss.
;-)
--
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ ftp: ftp://rtfm.mit.edu, C-FAQ Book: ISBN 0-201-84519-9
Try "C Programming: A Modern Approach" ISBN 0-393-96945-2
Dann Corbit
Dann Corbit wrote in message <6gb933$31b$1...@client3.news.psi.net>...
[snip]
>Well, the April 1 posts were rather explainable. I think the question was
>answered in other branches of the thread and fairly. Clearly, there are
>some arrogant posts from time to time. I think, however, that the
arrogance
>is mostly in the eye of the beholder; especially in the eye of ignorant,
>insufferable, moronic louts like you! And how dare you even suggest such a
>thing! It makes me whinge.
;-)
>By the way, anyone know what happened to Mr.
>Winters? I'm about ready to go into mourning at another tragic loss.
{Remove smiley from here.}
When I re-read the post, I saw that it might be taken in a way very opposite
from my intention.
Mark Brown
Rolf Magnus <rama...@zvw.nospam.de> writes:
> What is so bad about nesting comments in C? I can't find any
> disadvantage.
> I use nested comments sometimes, but my watcom c gives me a warning for
> every one it finds in my code...
Read the warnings! What they probably say is something along the
lines of "I'm going to let you do that just now, but if you try it on
another compiler, or even this compiler with different options, those
comments could stop working.". The comments in the standard C
language simply don't nest, so if you try and compile in a compiler
when it is enforcing this rule, the first */ in a "nested" comment
will signal the end of comments, and the compiler will then start to
try to interpret the rest of the comments as program text.
Rolf Magnus
Mark Brown wrote:
> Read the warnings! What they probably say is something along the
> lines of "I'm going to let you do that just now, but if you try it on
> another compiler, or even this compiler with different options, those
> comments could stop working.". The comments in the standard C
> language simply don't nest, so if you try and compile in a compiler
I know, but that's not the point. I wanted to know why nested comments
are not allowed. It would be better if they were.
> when it is enforcing this rule, the first */ in a "nested" comment
> will signal the end of comments, and the compiler will then start to
> try to interpret the rest of the comments as program text.
Some C compilers support nested comments (with warnings). So they
could work very well if it were in the c standard...
Rolf Magnus
Perique des Palottes wrote:
> No need to. Use:
>
> #if 0
> ...
> #endif
>
> as many times as you please to nest and renest ad infinitum.
Wouldn't it be better to simply use comments to 'comment' s.th out?
I mean in the way that is used on every other language.
What's the advantage of using such a strange way of commenting a
block of source out?
>
> Saying that is like saying that you like a lot to blow your head
> against the wall for the pleasure that comes from stopping to blow.
> Good luck.
No! It's more like I want to have the wall removed because it won't
let one come through and it has no practical use.
:-)
John Kugelman
Rolf Magnus wrote:
>
> Perique des Palottes wrote:
>
> > No need to. Use:
> >
> > #if 0
> > ...
> > #endif
> >
> > as many times as you please to nest and renest ad infinitum.
>
> Wouldn't it be better to simply use comments to 'comment' s.th out?
> I mean in the way that is used on every other language.
> What's the advantage of using such a strange way of commenting a
> block of source out?
Then pretend #if 0 is the begin comment symbol and #endif is the end
comment symbol. You can't place real comments in there, but that
doesn't matter since you would place real comments inside /* */
--
John Kugelman. kuge...@mnsinc.com
I believe we can change anything.
I believe in my dream.
- Joe Satriani
John Kugelman
But that's not the point of comments. Comments are for writing text to
describe how a program works, a bug in it, etc., not to "comment out"
code. That's what the pre-processor is for. If you want to write text
in your code, use comments, if you want to eliminate some code from
being compiled, wrap it in #ifdef 0 ... #endif
Chris Engebretson
In article <352A713D.3800@zvw.___PUT_DIZ_AWAY___de>,
Rolf Magnus <ramagnus@zvw.___PUT_DIZ_AWAY___de> writes:
|> Mark Brown wrote:
|>
|> > Read the warnings! What they probably say is something along the
|> > lines of "I'm going to let you do that just now, but if you try it on
|> > another compiler, or even this compiler with different options, those
|> > comments could stop working.". The comments in the standard C
|> > language simply don't nest, so if you try and compile in a compiler
|>
|> I know, but that's not the point. I wanted to know why nested comments
|> are not allowed. It would be better if they were.
Because the purpose of comments is to add documentation to a program.
They are *not* to provide for source code exclusion. There already
exist mechanisms to exclude lines of source code, such as the #if 0
method which has already been pointed out. Source code exclusion is
the only reasonable use for nested comments that I can think of.
Since the language already allows for this via existing means, I can
think of no good reason to add the "feature" of nested comments,
which also has the potential of breaking existing code.
/*********************
/* This is a comment *
/********************/
This is a perfectly legal C comment. Any C-like implementation where
nested comments are allowed will fail miserably upon encountering it.
Regards,
--
Chris Engebretson - Raytheon STX Corporation | Ph#: (605)594-6829
USGS EROS Data Center, Sioux Falls, SD 57198 | Fax: (605)594-6940
http://edcwww.cr.usgs.gov/ mailto:enge...@sg1.cr.usgs.gov
Opinions are not those of Raytheon Systems Company or the USGS.
Exil Q Trob
In article <352A72F3.1155@zvw.___PUT_DIZ_AWAY___de>,
ramagnus@zvw.___PUT_DIZ_AWAY___de says...
|
|Perique des Palottes wrote:
|>
|> Saying that is like saying that you like a lot to blow your head
|> against the wall for the pleasure that comes from stopping to blow.
|> Good luck.
|
|No! It's more like I want to have the wall removed because it won't
|let one come through and it has no practical use.
|:-)
... even though you now know where the architect put the door and the window?
David G
firewind
Rolf Magnus <ramagnus@zvw.___PUT_DIZ_AWAY___de> wrote:
> I know, but that's not the point. I wanted to know why nested comments
> are not allowed. It would be better if they were.
Nested comments are not allowed because they would complicate the parser
while providing absolutely no extra functionality. Nested comments in a
program are an error in a programming language that has a specific facility
to 'comment out' a block of code.
firewind
John Kugelman <kuge...@mnsinc.com> wrote:
> Then pretend #if 0 is the begin comment symbol and #endif is the end
> comment symbol. You can't place real comments in there,
That's not entirely true; for example, the following code snippet should
compile:
#if 0
You can compile this.
#endif
int main(void)
{
return(0);
}
but the following should not:
#if 0
You can't compile this.
#endif
int main(void)
{
return(0);
}
However, since natural language comments are not meant to be placed inside
the '#if' '#endif' preprocessing directives, it's a Really Bad Idea, and
should never be done.
> but that doesn't matter since you would place real comments inside /* */
Indeed.
firewind
Rolf Magnus <ramagnus@zvw.___PUT_DIZ_AWAY___de> wrote:
> Perique des Palottes wrote:
> > #if 0
> > ...
> > #endif
> Wouldn't it be better to simply use comments to 'comment' s.th out?
No. This is not what comments are for.
> I mean in the way that is used on every other language.
And if BASIC jumped off the Brooklyn Bridge.. er, sorry. :)
> What's the advantage of using such a strange way of commenting a
> block of source out?
It's not strange. You are informing the compiler that you wish this code to
be compiled only when 0 == 1, i.e., never. I consider the inclusion of code
in a mechanism intended to -document- things to be much, much stranger.
> No! It's more like I want to have the wall removed because it won't
> let one come through and it has no practical use.
You're right, but not in the way you think. Nested comments and the broken
compilers that allow them both have no practical use.
Michael Rubenstein
On 7 Apr 1998 23:28:11 GMT, firewind <fire...@metroid.dyn.ml.org>
wrote:
>John Kugelman <kuge...@mnsinc.com> wrote:
>> Then pretend #if 0 is the begin comment symbol and #endif is the end
>> comment symbol. You can't place real comments in there,
>
>That's not entirely true; for example, the following code snippet should
>compile:
>
> #if 0
> You can compile this.
> #endif
>
> int main(void)
> {
> return(0);
> }
>
>
>but the following should not:
>
> #if 0
> You can't compile this.
> #endif
>
> int main(void)
> {
> return(0);
> }
The standard doesn't prohibit that from compiling. Or not compiling.
Or causing demons to fly out of your nose. According to ISO 6.1, it
causes undefined behavior.
--
Michael M Rubenstein
Rolf Magnus
firewind wrote:
>
> Nested comments are not allowed because they would complicate the parser
> while providing absolutely no extra functionality. Nested comments in a
> program are an error in a programming language that has a specific facility
> to 'comment out' a block of code.
I don't think that it would complicate the parser so much that it could
really
be a problem. And the extra functionality is that you don't have to use
such
a nasty thing like #if 0 .
Nested comments are an error in a programming language? What the heck is
so
bad about them? Are they made by The Dark Side (tm) ? :-)
Rolf Magnus
firewind wrote:
> It's not strange. You are informing the compiler that you wish this code to
> be compiled only when 0 == 1, i.e., never. I consider the inclusion of code
And you don't find this strange? To tell a compiler to do s.th. only
when 0==1 ?
It's like you put up a sign at a road that says "only drive in here when
christmas and easter are on the same day" instead of simply saying
"don't drive in here!".
> You're right, but not in the way you think. Nested comments and the broken
> compilers that allow them both have no practical use.
My compiler has syntax highlighting. So comments have another color than
normal
code. When I use the #if 0 style, my excluded code will look like the
other code.
When using /* */, I can clearly see that it's commented out without
searching for
any #if's.
I hope my English is OK.
Rolf Magnus
Exil Q Trob wrote:
> |No! It's more like I want to have the wall removed because it won't
> |let one come through and it has no practical use.
> ... even though you now know where the architect put the door and the window?
The door isn't looking very good. How would it be to throw it away and
put in another
one?
Rolf Magnus
John Kugelman wrote:
> Then pretend #if 0 is the begin comment symbol and #endif is the end
> comment symbol. You can't place real comments in there, but that
> doesn't matter since you would place real comments inside /* */
So does the compiler parse through the 'commented' code chunk
although it doesn't use anything of it? Or did I misunderstand s.th?
Rolf Magnus
Er, sorry, but could you please point out the difference between this :
: #if 0
: You can compile this.
: #endif
:
: int main(void)
: {
: return(0);
: }
and the following code:
: #if 0
: You can't compile this.
: #endif
:
: int main(void)
: {
: return(0);
: }
???
I looked at it for 5 minutes, but can't find the difference. Maybe you
only forgot to modify something after cut'n'pate.
Will Rose
Rolf Magnus (ramagnus@zvw.___PUT_DIZ_AWAY___de) wrote:
: John Kugelman wrote:
The compiler doesn't go through it; the pre-processor does. The usual
problem is that the pre-processor sees a ''' character, and thinks
"whoopee, the start of a character constant". When the 'character
constant' doesn't end before the newline (since it's part of a word
such as "it's") the pre-processor sulks. It can probably be fooled
in other ways, but that's the main one I've seen.
Rolf Magnus
Chris Engebretson wrote:
>
> They are *not* to provide for source code exclusion. There already
> exist mechanisms to exclude lines of source code, such as the #if 0
> method which has already been pointed out. Source code exclusion is
I don't think that the #if command was made to comment out code in every
case. It's made to exlude a code block in a special case.
So you are 'misusing' the #if 0 directive exactly as I am 'misusing'
the comments.
> the only reasonable use for nested comments that I can think of.
> Since the language already allows for this via existing means, I can
> think of no good reason to add the "feature" of nested comments,
> which also has the potential of breaking existing code.
If someone makes comments in such a style that it wouldn't compile any
more, (s)he doesn't deserve running code... I think it's simply bad
style. And it would really not be difficult to correct it.
>
> /*********************
> /* This is a comment *
> /********************/
>
> This is a perfectly legal C comment. Any C-like implementation where
> nested comments are allowed will fail miserably upon encountering it.
Why? I thought about nested comments like this:
There is a /* that starts a comment and the next */ stops it. Everything
in
between is the comment and is in no way used by the compiler. This way
the above code WILL work. I haven't tried this on watcom c to see if it
works,
but I'll test it later.
Does the above code not use nested comments?
Ulric Eriksson
In article <352BB159.75FF@zvw.___PUT_DIZ_AWAY___de>,
Rolf Magnus <ramagnus@zvw.___REMOVE___de> wrote:
>Chris Engebretson wrote:
>
>> /*********************
>> /* This is a comment *
>> /********************/
>
/****************************
/* This is a nested comment */
****************************/
Ulric
Richard Stamp
In article <352BB159.75FF@zvw.___PUT_DIZ_AWAY___de>,
Rolf Magnus <ramagnus@zvw.___REMOVE___de> wrote:
>
>>
>> /*********************
>> /* This is a comment *
>> /********************/
>
>There is a /* that starts a comment and the next */ stops it. Everything
>in
>Does the above code not use nested comments?
Now I'm confused. What you've described above is exactly what happens
in C. After the /*, anything, including further /* combinations, is just
ignored until a */ is found. If that's what you mean by "nested comment",
then yes, C has "nested comments" and the above is one of them.
Most people mean the following by "nested comment":
/* Here's the start of a comment...
/* Now here's a nested comment.
The inner comment ends here: */
...but this is still part of the outer comment. */
Under C's rules the whole comment ends after 'here:'. To most people
"nested comment" would imply that the whole comment ends after 'comment.'
Cheers,
Richard
--
Richard Stamp
Churchill College, Cambridge
Jens Schweikhardt
Rolf Magnus <ramagnus@zvw.___PUT_DIZ_AWAY___de> wrote:
# Er, sorry, but could you please point out the difference between this :
# : #if 0
# : You can compile this.
# : #endif
# :
# : int main(void)
# : {
# : return(0);
# : }
# and the following code:
# : #if 0
# : You can't compile this.
# : #endif
# :
# : int main(void)
# : {
# : return(0);
# : }
Easy. You can compile the first, but not the second.
Why's that? Because any source file must consist
of what the Standard terms valid "preprocessing tokens".
You can't compile this.
aren't. It's two identifiers (You, can) followed
by an unterminated character constant ('t compile this.)
BARF.
Regards,
Jens
--
Jens Schweikhardt http://www.shuttle.de/schweikh
SIGSIG -- signature too long (core dumped)
Chris Engebretson
In article <352BB159.75FF@zvw.___PUT_DIZ_AWAY___de>,
Rolf Magnus <ramagnus@zvw.___PUT_DIZ_AWAY___de> writes:
[ trimmed "alt.tanaka-tomoyuki", whatever that is ]
|> Chris Engebretson wrote:
|>
|> > They are *not* to provide for source code exclusion. There already
|> > exist mechanisms to exclude lines of source code, such as the #if 0
|> > method which has already been pointed out. Source code exclusion is
|>
|> I don't think that the #if command was made to comment out code in every
|> case. It's made to exlude a code block in a special case.
|> So you are 'misusing' the #if 0 directive exactly as I am 'misusing'
|> the comments.
Congratulations! You've pegged the Nonsense Meter!
First of all, "#if 0" is not a misuse of the preprocessor. It is a
well-defined language construct that is described as the preferable
method to exclude a block of code by several sources, including the
Rationale for the ANSI C standard. The same cannot be said for
"nested comments", which are *forbidden* by the language definition.
Furthermore, by your logic,
while(1) {
/* .. main loop .. */
}
is a "misuse" of the while iteration-statement since it was made to
iterate only under "special" circumstances, and not forever.
The point is that temporarily removing a block of code is, by
definition, source code exclusion. This is exactly the service
that #if and #ifdef are intended to perform.
|> > the only reasonable use for nested comments that I can think of.
|> > Since the language already allows for this via existing means, I can
|> > think of no good reason to add the "feature" of nested comments,
|> > which also has the potential of breaking existing code.
|>
|> If someone makes comments in such a style that it wouldn't
|> compile any more, (s)he doesn't deserve running code...
Indeed! And nested comments fall directly into this category of
comments that you describe. An implementation that translates
nested comments as you seem to expect them to is most certainly not
acting as a C implementation. I certainly wouldn't expect running
code to be the result of source with nested comments.
|> > /*********************
|> > /* This is a comment *
|> > /********************/
|> >
|> > This is a perfectly legal C comment. Any C-like implementation where
|> > nested comments are allowed will fail miserably upon encountering it.
|>
|> Why? I thought about nested comments like this:
|> There is a /* that starts a comment and the next */ stops it.
|> Everything in between is the comment and is in no way used by the
|> compiler. This way the above code WILL work.
You've described how comments are *supposed* to work. A nested
comment is of the form
/* commenting out this next line
printf("%s\n", name); /* display the name */
*/
which should be written as
#if 0
printf("%s\n", name); /* display the name */
#endif
|> Does the above code not use nested comments?
No.
John Kugelman
Rolf Magnus wrote:
>
> John Kugelman wrote:
>
> > Then pretend #if 0 is the begin comment symbol and #endif is the end
> > comment symbol. You can't place real comments in there, but that
> > doesn't matter since you would place real comments inside /* */
>
> So does the compiler parse through the 'commented' code chunk
> although it doesn't use anything of it? Or did I misunderstand s.th?
Anything that will be excluded by the pre-processor still must consist
of valid tokens and must not have unterminated character- or
string-contants. So yes, it will still be parsed even if it will be
excluded from compilation.
John Kugelman
Rolf Magnus wrote:
>
> > You're right, but not in the way you think. Nested comments and the broken
> > compilers that allow them both have no practical use.
>
> My compiler has syntax highlighting. So comments have another color than
> normal
> code. When I use the #if 0 style, my excluded code will look like the
> other code.
> When using /* */, I can clearly see that it's commented out without
> searching for
> any #if's.
That's too bad, but that's not the C language's fault, only the
editor's.
> I hope my English is OK.
Your English is fine.
Lawrence Kirby
In article <352BB159.75FF@zvw.___PUT_DIZ_AWAY___de>
ramagnus@zvw.___REMOVE___de "Rolf Magnus" writes:
...
>> /*********************
>> /* This is a comment *
>> /********************/
>>
>> This is a perfectly legal C comment. Any C-like implementation where
>> nested comments are allowed will fail miserably upon encountering it.
>
>Why? I thought about nested comments like this:
>There is a /* that starts a comment and the next */ stops it. Everything
>in
>between is the comment and is in no way used by the compiler. This way
>the above code WILL work. I haven't tried this on watcom c to see if it
>works,
>but I'll test it later.
>
>Does the above code not use nested comments?
No, and what you describe is unnested comments. If /* */ comments nested then
the above code would open 3 levels of comment but only close one of them.
That would mean that any text following this would still be part of a comment
until the other two levels were closed.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Lawrence Kirby
In article <352BA1FA.7C01@zvw.___PUT_DIZ_AWAY___de>
ramagnus@zvw.___REMOVE___de "Rolf Magnus" writes:
>firewind wrote:
>
>> It's not strange. You are informing the compiler that you wish this code to
>> be compiled only when 0 == 1, i.e., never. I consider the inclusion of code
>
>And you don't find this strange? To tell a compiler to do s.th. only
>when 0==1 ?
>It's like you put up a sign at a road that says "only drive in here when
>christmas and easter are on the same day" instead of simply saying
>"don't drive in here!".
Yes, I do find this strange since #if 0 is unrelated to 0 == 1 (if anything
is is related to 0 != 0). However 0 is an idiomatic way in C of saying
"never". e.h. #if 0, if (0) {}, do {} while (0)
>> You're right, but not in the way you think. Nested comments and the broken
>> compilers that allow them both have no practical use.
>
>My compiler has syntax highlighting. So comments have another color than
>normal
>code. When I use the #if 0 style, my excluded code will look like the
>other code.
>When using /* */, I can clearly see that it's commented out without
>searching for
>any #if's.
The answer to that would be to get a compiler with better syntax highlighting.
I'm uneasy about moulding a whole coding style around a single compiler or
editor.
>I hope my English is OK.
It reads like you are fluent in the language.
Lawrence Kirby
In article <352BA387.19ED@zvw.___PUT_DIZ_AWAY___de>
ramagnus@zvw.___REMOVE___de "Rolf Magnus" writes:
>John Kugelman wrote:
>
>> Then pretend #if 0 is the begin comment symbol and #endif is the end
>> comment symbol. You can't place real comments in there, but that
>> doesn't matter since you would place real comments inside /* */
>
>So does the compiler parse through the 'commented' code chunk
>although it doesn't use anything of it? Or did I misunderstand s.th?
It preprocesses the code into tokens but it doesn't perform any syntax
analysis.
firewind
Rolf Magnus <ramagnus@zvw.___PUT_DIZ_AWAY___de> wrote:
> Exil Q Trob wrote:
> > ... even though you now know where the architect put the door and the
> > window?
> The door isn't looking very good. How would it be to throw it away and
> put in another one?
Since you aren't the architect who designed the house, it collapses when you
attempt to remove the door. Oops.
firewind
Rolf Magnus <ramagnus@zvw.___PUT_DIZ_AWAY___de> wrote:
> Er, sorry, but could you please point out the difference between this :
> : #if 0
> : You can compile this.
> : #endif
> and the following code:
> : #if 0
> : You can't compile this.
> : #endif
> ???
Did you try compiling it? The apostrophe in 'can't' begins a character constant
which is never terminated.
firewind
Rolf Magnus <ramagnus@zvw.___PUT_DIZ_AWAY___de> wrote:
> firewind wrote:
> > It's not strange. You are informing the compiler that you wish this code to
> > be compiled only when 0 == 1, i.e., never. I consider the inclusion of code
> And you don't find this strange? To tell a compiler to do s.th. only
> when 0==1 ?
I don't find it strange at all. When is '0 == 1' true? Never. Saying that I'm
testing for '0 == 1' is a misconception; I'm telling the compiler I -never-
want this code compiled. (Well, until I remove the '#if' / '#endif,' anyway :)
> It's like you put up a sign at a road that says "only drive in here when
> christmas and easter are on the same day" instead of simply saying
> "don't drive in here!".
Not at all. '#if 0' is an idiom, similar to, for example 'if(!p)'. Taken
literally ('if 0' or 'if not p') they don't make sense; taken with the meaning
they were intended to hold, they make perfect sense.
I'm curious, how else would you like 'don't drive in here' to be written, in
C?
> > You're right, but not in the way you think. Nested comments and the broken
> > compilers that allow them both have no practical use.
> My compiler has syntax highlighting.
No, it doesn't. Your -editor- has syntax highlighting.
> So comments have another color than normal code. When I use the #if 0
> style, my excluded code will look like the other code.
That's funny. All of -my- code looks the same color. ;)
firewind
Rolf Magnus <ramagnus@zvw.___PUT_DIZ_AWAY___de> wrote:
> Chris Engebretson wrote:
> > They are *not* to provide for source code exclusion. There already
> > exist mechanisms to exclude lines of source code, such as the #if 0
> > method which has already been pointed out. Source code exclusion is
> I don't think that the #if command was made to comment out code in every
> case.
That's true. '#if' was introduced to compile code under certain circumstances.
The '#if 0' situation indicates that the code is to be compiled under -no-
circumstances.
> It's made to exlude a code block in a special case.
Right; 'never' is just one of these special cases.
> So you are 'misusing' the #if 0 directive exactly as I am 'misusing'
> the comments.
Incorrect. What, precisely, about 'never' makes it unsuitable for being a
special case?
> > the only reasonable use for nested comments that I can think of.
> > Since the language already allows for this via existing means, I can
> > think of no good reason to add the "feature" of nested comments,
> > which also has the potential of breaking existing code.
> If someone makes comments in such a style that it wouldn't compile any
> more, (s)he doesn't deserve running code... I think it's simply bad
> style.
This is ridiculous. People who make strictly-conforming C89 code 'don't deserve
running code' because when you compile it with your idiotic extensions, it
breaks?
> > /*********************
> > /* This is a comment *
> > /********************/
> >
> > This is a perfectly legal C comment. Any C-like implementation where
> > nested comments are allowed will fail miserably upon encountering it.
> Why? I thought about nested comments like this:
> There is a /* that starts a comment and the next */ stops it. Everything
> in between is the comment and is in no way used by the compiler. This way
> the above code WILL work.
It will? The above comment block 'opens' three times, but only 'closes' once.
> Does the above code not use nested comments?
No, it doesn't. The usage of extra '/' characters and a 'border' of asterisks
is a certain comment style, entirely legal under C89. However, with the
introduction of nested-comment extensions, it breaks.
firewind
Rolf Magnus <ramagnus@zvw.___PUT_DIZ_AWAY___de> wrote:
> firewind wrote:
> > while providing absolutely no extra functionality. Nested comments in a
> > program are an error in a programming language that has a specific facility
> > to 'comment out' a block of code.
> I don't think that it would complicate the parser so much that it could
> really be a problem.
Maybe not. Maybe it would, depending on the parser. That's not the point.
> And the extra functionality is that you don't have to use such a nasty thing
> like #if 0 .
Could you explain the 'evilness' of '#if 0'? Disregarding, of course, the
entirely irrelevant point that it 'doesn't look pretty' under your particular
editor.
> Nested comments are an error in a programming language?
No; you stopped reading after 'language.' Try again.
Rolf Magnus
firewind wrote:
> > So you are 'misusing' the #if 0 directive exactly as I am 'misusing'
> > the comments.
>
> Incorrect. What, precisely, about 'never' makes it unsuitable for being a
> special case?
What precisely about comments makes it unsuitable for removing code?
> This is ridiculous. People who make strictly-conforming C89 code 'don't deserve
> running code' because when you compile it with your idiotic extensions, it
> breaks?
Being it C89 code doesn't mean that it's the better way. Why should
someone use
such an 'idiotic' comment such as the one below?
> > > /*********************
> > > /* This is a comment *
> > > /********************/
> > There is a /* that starts a comment and the next */ stops it. Everything
> > in between is the comment and is in no way used by the compiler. This way
> > the above code WILL work.
>
> It will? The above comment block 'opens' three times, but only 'closes' once.
You should try to read what I write to be able to give a right answer!
I wrote that after the comment opened once, EVERYTHING that does NOT
close the
comment should be IGNORED! So this would be valid code even if the inner
comment
is not right.
Rolf Magnus
Lawrence Kirby wrote:
> No, and what you describe is unnested comments. If /* */ comments nested then
> the above code would open 3 levels of comment but only close one of them.
> That would mean that any text following this would still be part of a comment
> until the other two levels were closed.
Yes, I saw the problem, as I posted somewhere else.
But I also said that I don't think this code is good style. Is such a
code
really used often in real world?
Rolf Magnus
Chris Engebretson wrote:
> First of all, "#if 0" is not a misuse of the preprocessor. It is a
> well-defined language construct that is described as the preferable
> method to exclude a block of code by several sources, including the
> Rationale for the ANSI C standard. The same cannot be said for
> "nested comments", which are *forbidden* by the language definition.
It's a "preferable" method? I'd more like to say that it's the only
method. It's easy to say that s.th is best when there is no other
choice.
> Furthermore, by your logic,
>
> while(1) {
> /* .. main loop .. */
> }
>
> is a "misuse" of the while iteration-statement since it was made to
> iterate only under "special" circumstances, and not forever.
Extactly! Why is c the only language that uses such things? Maybe it's
in the standard, but does that make it good?
>
> The point is that temporarily removing a block of code is, by
> definition, source code exclusion. This is exactly the service
> that #if and #ifdef are intended to perform.
>
> |> If someone makes comments in such a style that it wouldn't
> |> compile any more, (s)he doesn't deserve running code...
>
> Indeed! And nested comments fall directly into this category of
> comments that you describe. An implementation that translates
> nested comments as you seem to expect them to is most certainly not
> acting as a C implementation. I certainly wouldn't expect running
> code to be the result of source with nested comments.
I *KNOW* that nested comments are not in any c standard!
But IMO, they should.
> You've described how comments are *supposed* to work. A nested
> comment is of the form
>
> /* commenting out this next line
> printf("%s\n", name); /* display the name */
> */
That's right. I see the problen. I cannot use the firsrt */ to close
the comment. Sry, my fault. So the example with 3 /* and only one */
does indeed not work... So I can accept that it would be a big problem
to do such a change in c standard.
But I am not only talking about a change, but generally about nested
comments and their use.
Will Rose
Rolf Magnus (ramagnus@zvw.___PUT_DIZ_AWAY___de) wrote:
[...]
: Being it C89 code doesn't mean that it's the better way. Why should
: someone use
: such an 'idiotic' comment such as the one below?
:
: > > > /*********************
: > > > /* This is a comment *
: > > > /********************/
: > > There is a /* that starts a comment and the next */ stops it. Everything
: > > in between is the comment and is in no way used by the compiler. This way
: > > the above code WILL work.
: >
: > It will? The above comment block 'opens' three times, but only 'closes' once.
: You should try to read what I write to be able to give a right answer!
: I wrote that after the comment opened once, EVERYTHING that does NOT
: close the
: comment should be IGNORED! So this would be valid code even if the inner
: comment is not right.
Er, there's some confusion here. Everything that does not close the
comment _is_ being ignored. That's how comments work in C; opening
a second comment inside a comment is ignored.
Rolf Magnus
firewind wrote:
> Did you try compiling it? The apostrophe in 'can't' begins a character constant
> which is never terminated.
No, I didn't. But what a nasty trick! So if I have some code that is
incomplete
or does have errors, I can't remove it with #if 0 ? I thought that you
can
completely remove code with it so the compiler ignores it. Now you say
that
this is not the case? Isn't that a disadvantage?
Rolf Magnus
firewind wrote:
> This is ridiculous. People who make strictly-conforming C89 code 'don't deserve
> running code' because when you compile it with your idiotic extensions, it
> breaks?
What about gets() ? Is it the best way to use it because it's standard
c? I
learned using gets() in school. Before reading this newsgroup I didn't
even
know about any problem with it. I know many ppl that don't know and
therefore use it.
There are many things that are considered bad style, but confirm the
standard.
Ulric Eriksson
In article <352CF5AC.16CC@zvw.___PUT_DIZ_AWAY___de>,
Rolf Magnus <ramagnus@zvw.___REMOVE___de> wrote:
>firewind wrote:
>
>> This is ridiculous. People who make strictly-conforming C89 code 'don't deserve
>> running code' because when you compile it with your idiotic extensions, it
>> breaks?
>
>What about gets() ? Is it the best way to use it because it's standard
>c? I
>learned using gets() in school. Before reading this newsgroup I didn't
>even
>know about any problem with it. I know many ppl that don't know and
>therefore use it.
There are alternatives to gets() which are also standard. There are
no standard alternatives to #if 0.
Ulric
Ulric Eriksson
In article <352CED4E.1F3C@zvw.___PUT_DIZ_AWAY___de>,
Rolf Magnus <ramagnus@zvw.___REMOVE___de> wrote:
>Chris Engebretson wrote:
>
>> Furthermore, by your logic,
>>
>> while(1) {
>> /* .. main loop .. */
>> }
>>
>> is a "misuse" of the while iteration-statement since it was made to
>> iterate only under "special" circumstances, and not forever.
>
>Extactly! Why is c the only language that uses such things? Maybe it's
>in the standard, but does that make it good?
What languages don't allow endless loops?
Ulric
Alex Krol
Rolf Magnus wrote:
>
> firewind wrote:
>
> > > So you are 'misusing' the #if 0 directive exactly as I am 'misusing'
> > > the comments.
> >
> > Incorrect. What, precisely, about 'never' makes it unsuitable for being a
> > special case?
>
> What precisely about comments makes it unsuitable for removing code?
>
> > running code' because when you compile it with your idiotic extensions, it
> > breaks?
>
> someone use
> such an 'idiotic' comment such as the one below?
>
> > > > /*********************
> > > > /* This is a comment *
> > > > /********************/
>
> > > There is a /* that starts a comment and the next */ stops it. Everything
> > > in between is the comment and is in no way used by the compiler. This way
> > > the above code WILL work.
> >
> > It will? The above comment block 'opens' three times, but only 'closes' once.
>
> You should try to read what I write to be able to give a right answer!
> I wrote that after the comment opened once, EVERYTHING that does NOT
> close the
> comment should be IGNORED! So this would be valid code even if the inner
> comment
> is not right.
You can't have it both ways. If the statement above is true, you
can't have nested comments. If you do have nested comments, the quoted
example fails to compile.
Nested comments do not solve any pressing problem. The only possible
practical use for them is to exclude part of code - and for this
you do have conditional compilation.
Regards,
Alex Krol
John Kugelman
Rolf Magnus wrote:
>
> What precisely about comments makes it unsuitable for removing code?
They don't work well when the code being removed contains other
comments, but #if 0/#endif does.
> Being it C89 code doesn't mean that it's the better way. Why should
> someone use such an 'idiotic' comment such as the one below?
I don't see anything wrong with it. Tell me what's so idiotic.
Besides, calling something idiotic doesn't mean it shouldn't work if
it's defined to work.
> > > > /*********************
> > > > /* This is a comment *
> > > > /********************/
>
> > It will? The above comment block 'opens' three times, but only 'closes' once.
>
> You should try to read what I write to be able to give a right answer!
> I wrote that after the comment opened once, EVERYTHING that does NOT
> close the comment should be IGNORED! So this would be valid code even
> if the inner comment is not right.
That's exactly how comments work now! If you want nested comments then
the comment above would NOT work, because it would open three times and
close only once, which is exactly what firewind said! Which do you
want?
John Kugelman
Rolf Magnus wrote:
>
> Chris Engebretson wrote:
>
> > First of all, "#if 0" is not a misuse of the preprocessor. It is a
> > well-defined language construct that is described as the preferable
> > method to exclude a block of code by several sources, including the
> > Rationale for the ANSI C standard. The same cannot be said for
> > "nested comments", which are *forbidden* by the language definition.
>
> It's a "preferable" method? I'd more like to say that it's the only
> method. It's easy to say that s.th is best when there is no other
> choice.
No, you can also "comment out" code with /* and */, but it doesn't work
quite as well.
> > Furthermore, by your logic,
> >
> > while(1) {
> > /* .. main loop .. */
> > }
> >
> > is a "misuse" of the while iteration-statement since it was made to
> > iterate only under "special" circumstances, and not forever.
>
> Extactly! Why is c the only language that uses such things? Maybe it's
> in the standard, but does that make it good?
What's wrong with it? What would you use to create infinite loops? You
can't use while, can't use for, what then? goto? In Pascal I would
write while (TRUE), which is semantically identical.
> I *KNOW* that nested comments are not in any c standard!
> But IMO, they should.
If they provided some extra functionality that was already not in the
language someone might care, but they don't, so get over it.
> > /* commenting out this next line
> > printf("%s\n", name); /* display the name */
> > */
>
> That's right. I see the problen. I cannot use the first */ to close
> the comment. Sry, my fault. So the example with 3 /* and only one */
> does indeed not work... So I can accept that it would be a big problem
> to do such a change in c standard.
> But I am not only talking about a change, but generally about nested
> comments and their use.
Comments are for comments. Excluding code from compilation is not done
to document source code, so comments are not what are needed. This is
what the pre-processor was MADE for, it's been sitting there just
WAITING for you to start sticking some #ifs and #endifs, so use it.
I haven't seen you mention any disadvantages of using the preprocessor
to exclude code except that your editor doesn't color the code
differently (which is your editor's fault, not the language's). If
that's all you can come up with you'd better just stop now.
Richard Stamp
In article <352CE044...@mnsinc.com>,
John Kugelman <kuge...@mnsinc.com> wrote:
>
[while(1) for an infinite loop]
>
>What's wrong with it? What would you use to create infinite loops? You
>can't use while, can't use for, what then? goto? In Pascal I would
>write while (TRUE), which is semantically identical.
Modula-3 has a separate construct for an infinite loop (LOOP...END, I think,
but it's been a while). On reflection I like this. If you don't agree I
don't think I can say anything which will make you understand my point of
view, but to me it does seem ugly to bend the syntax of "loop which
terminates when something happens" to make a "loop which never terminates".
Of course it is massively too late to retrofit any such construct to C,
but this thread is entirely speculative anyway. :-)
Similarly I've never really liked the '#if 0' way of removing a section
of code. Yes, it's what you do in C and it's pointless to whine about it,
but if I were inventing a programming language from scratch I'd have some
way of (for want of a better term) temporarily "commenting out" code
distinct from both the commenting and the conditional compilation
mechanisms.
Will Rose
Richard Stamp (rg...@cam.ac.uk) wrote:
: In article <352CE044...@mnsinc.com>,
: John Kugelman <kuge...@mnsinc.com> wrote:
: >
: [while(1) for an infinite loop]
: >
: >What's wrong with it? What would you use to create infinite loops? You
: >can't use while, can't use for, what then? goto? In Pascal I would
: >write while (TRUE), which is semantically identical.
: Modula-3 has a separate construct for an infinite loop (LOOP...END, I think,
: but it's been a while). On reflection I like this. If you don't agree I
: don't think I can say anything which will make you understand my point of
: view, but to me it does seem ugly to bend the syntax of "loop which
: terminates when something happens" to make a "loop which never terminates".
I use 'while (TRUE)' for do...forever, and it seems clear enough; obviously
there has to be a define of TRUE somewhere. Many people use 'for (;;)'
which I find a bit obscure.
: Of course it is massively too late to retrofit any such construct to C,
: but this thread is entirely speculative anyway. :-)
: Similarly I've never really liked the '#if 0' way of removing a section
: of code. Yes, it's what you do in C and it's pointless to whine about it,
: but if I were inventing a programming language from scratch I'd have some
: way of (for want of a better term) temporarily "commenting out" code
: distinct from both the commenting and the conditional compilation
: mechanisms.
Well, I don't really see it as commenting out code; comments are comments,
and conditional compilation is conditional compilation. Using comments
to control compilation seems to me a kludge, tho' it's quite commonly done.
Why not use the explicit control mechanism, since it's available?
John Kugelman
Richard Stamp wrote:
>
> In article <352CE044...@mnsinc.com>,
> John Kugelman <kuge...@mnsinc.com> wrote:
> >
> [while(1) for an infinite loop]
> >
> >What's wrong with it? What would you use to create infinite loops? You
> >can't use while, can't use for, what then? goto? In Pascal I would
> >write while (TRUE), which is semantically identical.
>
> Modula-3 has a separate construct for an infinite loop (LOOP...END, I think,
> but it's been a while). On reflection I like this. If you don't agree I
> don't think I can say anything which will make you understand my point of
> view, but to me it does seem ugly to bend the syntax of "loop which
> terminates when something happens" to make a "loop which never terminates".
It depends, I stopped thinking of loops as "things which terminate
when..." because many people ignore the fact that they're supposed to
terminate. When I first saw the while (true) type condition I freaked
out, but I freaked out on a = a + 1, too, so that's not saying much.
It's not hard to get used to, and then to appreciate. But, you could
always do something like:
#define ever ;1;
for(ever)
{
John Kugelman
Ulric Eriksson wrote:
>
> What languages don't allow endless loops?
Early BASICs that didn't have loops.
firewind
Rolf Magnus <ramagnus@zvw.___PUT_DIZ_AWAY___de> wrote:
> firewind wrote:
> > deserve running code' because when you compile it with your idiotic
> > extensions, it breaks?
> What about gets() ?
What about 'gets()'?
> Is it the best way to use it because it's standard c?
No. As I'm -sure- you know, the standard also provides 'fgets().'
> I learned using gets() in school.
I'm sorry to hear that.
> Before reading this newsgroup I didn't even know about any problem with it.
I'm glad you learned something from comp.lang.c. Now learn -this- from
comp.lang.c: nested comments do not belong in C.
> I know many ppl that don't know and therefore use it.
Why don't you educate them?
> There are many things that are considered bad style, but confirm the
> standard.
So the purpose of this post was what? Comment styles such as
/************
/* Hi there *
/***********/
are not considered to be bad style; if you could point out any disadvantages,
rooted in fact, please, concerning them, I'll be more than happy to change
my mind.
firewind
Rolf Magnus <ramagnus@zvw.___PUT_DIZ_AWAY___de> wrote:
> firewind wrote:
> > special case?
> What precisely about comments makes it unsuitable for removing code?
Which part of 'natural language' don't you understand? Which part of 'no
nested comments' don't you understand?
> > This is ridiculous. People who make strictly-conforming C89 code 'don't
> > deserve running code' because when you compile it with your idiotic
> > extensions, it breaks?
> Being it C89 code doesn't mean that it's the better way.
Given a standard method and a non-standard method, the standard method is
better 100% of the time.
> Why should someone use such an 'idiotic' comment such as the one below?
As I just said, if you can point out any factual problems with the comment
style, I will accept your judgement of its idiocy.
> > > > /*********************
> > > > /* This is a comment *
> > > > /********************/
> > > There is a /* that starts a comment and the next */ stops it. Everything
> > > in between is the comment and is in no way used by the compiler. This way
> > > the above code WILL work.
> >
> > It will? The above comment block 'opens' three times, but only 'closes'
> > once.
> You should try to read what I write to be able to give a right answer!
You should decide what your position is so as not to confuse those you are
speaking with.
> I wrote that after the comment opened once, EVERYTHING that does NOT
> close the comment should be IGNORED!
That is consistent with current comment rules, but not 'nested comment' rules.
firewind
Rolf Magnus <ramagnus@zvw.___PUT_DIZ_AWAY___de> wrote:
> Chris Engebretson wrote:
> >
> > while(1) {
> > /* .. main loop .. */
> > }
> >
> Extactly!
Are you a troll?
> Why is c the only language that uses such things?
Because C is better than other languages?
> Maybe it's in the standard, but does that make it good?
Maybe you don't like it, but does that make it bad?
> I *KNOW* that nested comments are not in any c standard!
> But IMO, they should.
For what purpose? And why is this mythical purpose worth making thousands of
conforming programs non-conforming?
firewind
John Kugelman <kuge...@mnsinc.com> wrote:
> Ulric Eriksson wrote:
> > What languages don't allow endless loops?
> Early BASICs that didn't have loops.
Bullshit.
10 PRINT "HELLO WORLD"
20 GOTO 10
RUN
Endless loop.
firewind
Rolf Magnus <ramagnus@zvw.___PUT_DIZ_AWAY___de> wrote:
> But I also said that I don't think this code is good style. Is such a
> code really used often in real world?
Yes. And it is 'not good style' only in the fevered imaginations of those
who cannot grasp that C does not and will never have nested comments.
firewind
Rolf Magnus <ramagnus@zvw.___PUT_DIZ_AWAY___de> wrote:
> firewind wrote:
> > constant which is never terminated.
> No, I didn't. But what a nasty trick!
Quite. So don't do it.
> So if I have some code that is incomplete or does have errors, I can't
> remove it with #if 0 ?
-Where- did you get that idea? Of course you can... to a degree. You see,
in order to be able to find the '#endif' to accompany the '#if,' the
preprocessor (or equivilant) must do -some- parsing of whatever text may
lie inbetween. Basically, it continues through the '#if'd out code, breaking
it up into 'preprocessing tokens.' When the preprocessor encounters the
apostrophe character, everything from the next character until the next
apostrophe is part of the same token. Therefore, two errors are present:
the character constant is never closed, and neither is the '#if'. However,
none of this stops you from '#if'ing out incomplete code; the following is
valid:
#if 0
int foo(char *baz)
{
printf("%c,"
#endif
> I thought that you can completely remove code with it so the compiler
> ignores it.
The only way to completely remove code is to remove it from the source file.
> Now you say that this is not the case?
As far as Joe Coder knows, it is. As long as Joe Coder doesn't do anything
stupid (like attempt to insert natural language inside an '#if') he will be
fine.
> Isn't that a disadvantage?
No. How would you handle an unterminated character constant? And still be able
to locate the '#endif' directive?
--
Richard Stamp
In article <352D2CE...@mnsinc.com>,
John Kugelman <kuge...@mnsinc.com> wrote:
>
>But, you could always do something like:
>
>#define ever ;1;
>
>for(ever)
>{
>}
Pah! My version is *much* more intuitive and readable:
#define repeat do
#define until(x) while (!(x))
#define hell_freezes_over 0
:-)
Richard Stamp
In article <89214956...@optional.cts.com>, Will Rose <c...@cts.com> wrote:
>
>Well, I don't really see it as commenting out code; comments are comments,
>and conditional compilation is conditional compilation. Using comments
>to control compilation seems to me a kludge, tho' it's quite commonly done.
>Why not use the explicit control mechanism, since it's available?
I said "commenting out" because I couldn't think of a better shorthand
way of expressing it. I don't *really* see it as commenting out either.
The way I look at it is this: if you "comment out" ("#if 0" out, whatever)
a block of code, what you're doing is in some sense temporary. If you
wanted that code to be excluded forever you'd just delete it. It's a
sort of programmer's convenience device. By contrast conditional
compilation directives are often found in a finished product -- they're
"real" code.
So it seems equally kludgey to use the conditional compilation mechanism
to exclude code temporarily. I think comments, conditional compilation
and "commenting out" code are three quite different things and I'd like
to have had three separate ways of doing them. It's too late now!
Michael Rubenstein
On Thu, 09 Apr 1998 16:18:33 -0400, John Kugelman
<kuge...@mnsinc.com> wrote:
>Ulric Eriksson wrote:
>>
>> What languages don't allow endless loops?
>
>Early BASICs that didn't have loops.
Unless premature senility is making me lose my memory,
10 goto 10
was legal in the first version of basic.
--
Michael M Rubenstein
John Kugelman
Exil Q Trob wrote:
>
> In article <352D2D19...@mnsinc.com>, kuge...@mnsinc.com says...
> >
> >> What languages don't allow endless loops?
> >
> >Early BASICs that didn't have loops.
>
> when necessary.
>
> David G
But gotos and ifs don't create loops, they just simulate them. Loops
are able to have constructs like "break" and "continue," ifs and gotos
can't do those things without using even more ifs and gotos.
Craig Franck
Rolf Magnus <ramagnus@zvw.___PUT_DIZ_AWAY___de> wrote:
>Chris Engebretson wrote:
>> Furthermore, by your logic,
>>
>> while(1) {
>> /* .. main loop .. */
>> }
>>
>> is a "misuse" of the while iteration-statement since it was made to
>> iterate only under "special" circumstances, and not forever.
>
>Extactly! Why is c the only language that uses such things? Maybe it's
>in the standard, but does that make it good?
Every language I've used allows you to construct an infinite loop
in a very similar fashon. Some languages don't need a condition at
all:
-- Ada example
Loop
-- statements
End Loop;
But not all languages have such a loop built right into them.
>I *KNOW* that nested comments are not in any c standard!
>But IMO, they should.
I don't see any compelling reason for their inclusion.
In the next C revision you may have the option of using end of
line comments, which cause less trouble when "commented out".
--
Craig
clfr...@worldnet.att.net
Manchester, NH
I love the smell of commerce in the morning.
-- Brodie, "Mallrats"
Exil Q Trob
Craig Franck
firewind wrote:
>-Where- did you get that idea? Of course you can... to a degree. You see,
>in order to be able to find the '#endif' to accompany the '#if,' the
>preprocessor (or equivilant) must do -some- parsing of whatever text may
>lie inbetween. Basically, it continues through the '#if'd out code, breaking
>it up into 'preprocessing tokens.' When the preprocessor encounters the
>apostrophe character, everything from the next character until the next
>apostrophe is part of the same token. Therefore, two errors are present:
>the character constant is never closed, and neither is the '#if'. However,
>none of this stops you from '#if'ing out incomplete code; the following is
>valid:
>
> #if 0
> int foo(char *baz)
> {
> printf("%c,"
> #endif
[...]
>> Isn't that a disadvantage?
>
>No. How would you handle an unterminated character constant? And still be able
>to locate the '#endif' directive?
The fact that the preprocessing directive must be on a new-line would
enable you to diagnose an "unterminated string or character constant"
when the new-line is encountered, and then start parsing the directive.
#if 0
int foo(char *baz)
{
printf("%c,
#endif
printf"%c, breaks at the new-line. #endif sits on the next one. The
compiler would still have to issue a diagnostic, but it could locate
the #endif reliably. [This may be a quality of implementation issue
in the sense that what we are talking about (finding the #endif)
has to do with how well the compiler recovers from an error in the
source code.]
Michael Rubenstein
On 10 Apr 1998 02:01:30 GMT, Craig Franck <clfr...@worldnet.att.net>
wrote:
No. The compiler would NOT have to issue a diagnostic. An unmatched
" or ' preprocessing token results in undefined behavior. No
diagnostic is required.
--
Michael M Rubenstein
r...@cs.wisc.edu
In article <6gjl55$g46$5...@usenet11.supernews.com>,
firewind <fire...@metroid.dyn.ml.org> wrote:
> .... Comment styles such as
>
> /************
> /* Hi there *
> /***********/
>
> are not considered to be bad style; if you could point out any disadvantages,
> rooted in fact, please, concerning them, I'll be more than happy to change
> my mind.
One disadvantage is that someone maintaining your code might
delete the last line only, thinking it was the entire comment. The
maintainer can tell from the last line that the comment has ended
but has to look back to the end of the preceding comment (or the
start of the file) and then forward again to be sure of where it started.
If you know there are no comments like this, you can simply search
forward for */ and backward to /* to find the ends of the comment
you're in.
--
MJSR
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Sunil Rao
Craig Franck <clfr...@worldnet.att.net> wrote, and I reply...
>Every language I've used allows you to construct an infinite loop
>in a very similar fashon. Some languages don't need a condition at
>all:
>
>-- Ada example
>
>Loop
> -- statements
>End Loop;
>
>But not all languages have such a loop built right into them.
Structured BASIC does, actually... :^)
DO
stuff...
LOOP
--
sunil rao <su...@raos.demon.co.uk> <suni...@iloveindia.com>
"oru whisky, oru masala dosa... MIND it..."
aaaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhhhhhhhhhh..................
Craig Franck
John Kugelman <kuge...@mnsinc.com> wrote:
>are able to have constructs like "break" and "continue," ifs and gotos
>can't do those things without using even more ifs and gotos.
The definition of a structured loop has nothing to do with "break" or
"continue" constructs. Both of them tend to destructure the loop,
although, in an infinite loop, a break construct would be helpful. But
you still tend to use them with if statements. "break and "continue"
are really just glorified gotos.
DIM i AS INTEGER
i = 0
continue:
top:
i = i + 1
IF i MOD 2 GOTO continue
IF i > 10 GOTO break
PRINT i
GOTO top
break:
Lawrence Kirby
In article <352CE8A4.6AF9@zvw.___PUT_DIZ_AWAY___de>
ramagnus@zvw.___REMOVE___de "Rolf Magnus" writes:
>firewind wrote:
>
>> > So you are 'misusing' the #if 0 directive exactly as I am 'misusing'
>> > the comments.
>>
>> Incorrect. What, precisely, about 'never' makes it unsuitable for being a
>> special case?
>
>What precisely about comments makes it unsuitable for removing code?
Because that is not their purpose. Comments are for code documentaton, not
code removal. Conditional code inclusion is precisely what preprocessor
directives like #if and #ifdef are for.
Since comments don't nest in C "commenting out" code is going to get you
into trouble of that code already contains comments. C is better off
with non-nesting comments because nesting is not appropiate for a
comment's primary purpose: commenting.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Tom Torfs
John Kugelman wrote in a message to All:
> What languages don't allow endless loops?
JK> Early BASICs that didn't have loops.
They must have had a goto then, right ? And with a goto an endless loop
is a piece of cake.
greetings,
Tom
tomt...@village.uunet.be
John Kugelman
>
>
>
> 10 PRINT "HELLO WORLD"
> 20 GOTO 10
> RUN
>
> Endless loop.
I don't call that a loop, I call it a goto. Of course, if you're happy
with just ifs and gotos, why are you using C?
John Kugelman
Michael Rubenstein wrote:
>
> On Thu, 09 Apr 1998 16:18:33 -0400, John Kugelman
> <kuge...@mnsinc.com> wrote:
>
> >Ulric Eriksson wrote:
> >>
> >> What languages don't allow endless loops?
> >
> >Early BASICs that didn't have loops.
>
>
> 10 goto 10
>
> was legal in the first version of basic.
That's recursion. Oh, maybe not, the stack isn't going to overflow...
John Kugelman
Tom Torfs wrote:
>
> John Kugelman wrote in a message to All:
>
>
>
> They must have had a goto then, right ? And with a goto an endless loop
> is a piece of cake.
Grrr, since everyone else seems to think this is a loop, I must concur.
However, I thought one of the main improvements of structured
programming over BASIC was loops.
Sue Spence
John Kugelman wrote:
Can't think of any off-hand.
> >
> > > Early BASICs that didn't have loops.
> >
> > Bullshit.
> >
> > 10 PRINT "HELLO WORLD"
> > 20 GOTO 10
> > RUN
> >
> > Endless loop.
>
> I don't call that a loop, I call it a goto.
It looks like a loop, it acts like a loop, and you know what -- it IS a
loop.
> Of course, if you're happy
> with just ifs and gotos, why are you using C?
>
Non-sequitur.
Sue Spence
John Kugelman wrote:
>
> Michael Rubenstein wrote:
> >
> > <kuge...@mnsinc.com> wrote:
> >
> > >Ulric Eriksson wrote:
> > >>
> > >> What languages don't allow endless loops?
> > >
> >
> >
> > 10 goto 10
> >
> > was legal in the first version of basic.
>
> That's recursion.
No, it isn't.
10 goto 10
is a nice tight INFINITE LOOP.
> Oh, maybe not, the stack isn't going to overflow...
Umm, the definition of "recursion" isn't "technique which makes the
stack overflow".
>Grrr, since everyone else seems to think this is a loop, I must concur.
>However, I thought one of the main improvements of structured
>programming over BASIC was loops.
Not quite. One of the main improvements of so-called structured
programming over so-called unstructured languages such as BASIC was the
advent of LOOP CONSTRUCTS (for/while/do-while/etc). We even have loops
in assembly language, John. How do you think the higher-level languages
with their fancy loop constructs are implemented on the machine itself?