Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #13110 > unrolled thread

Why don't C comments nest?

Back to article view | Back to comp.lang.c

Contents

  Why don't C comments nest? Aron Packer <atp1@rightthing.invalid> - 2011-11-11 19:21 +0000
    Re: Why don't C comments nest? James Kuyper <jameskuyper@verizon.net> - 2011-11-11 14:31 -0500
      Re: Why don't C comments nest? Noob <root@127.0.0.1> - 2011-11-17 11:21 +0100
        Re: Why don't C comments nest? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-18 15:55 +0200
    Re: Why don't C comments nest? nroberts <roberts.noah@gmail.com> - 2011-11-11 11:25 -0800
    Re: Why don't C comments nest? Kaz Kylheku <kaz@kylheku.com> - 2011-11-11 20:11 +0000
      Re: Why don't C comments nest? "BartC" <bc@freeuk.com> - 2011-11-11 20:28 +0000
        Re: Why don't C comments nest? Keith Thompson <kst-u@mib.org> - 2011-11-11 13:16 -0800
          Re: Why don't C comments nest? James Kuyper <jameskuyper@verizon.net> - 2011-11-11 16:28 -0500
            Re: Why don't C comments nest? Keith Thompson <kst-u@mib.org> - 2011-11-11 13:54 -0800
              Re: Why don't C comments nest? Willem <willem@toad.stack.nl> - 2011-11-12 12:07 +0000
                Re: Why don't C comments nest? Keith Thompson <kst-u@mib.org> - 2011-11-12 13:11 -0800
                  Re: Why don't C comments nest? Willem <willem@toad.stack.nl> - 2011-11-12 22:29 +0000
                    Re: Why don't C comments nest? Keith Thompson <kst-u@mib.org> - 2011-11-12 16:36 -0800
                      Re: Why don't C comments nest? Willem <willem@toad.stack.nl> - 2011-11-13 10:30 +0000
                        Re: Why don't C comments nest? James Kuyper <jameskuyper@verizon.net> - 2011-11-13 06:31 -0500
                          Re: Why don't C comments nest? Willem <willem@toad.stack.nl> - 2011-11-13 16:57 +0000
              Re: Why don't C comments nest? Stephen Sprunk <stephen@sprunk.org> - 2011-11-12 08:21 -0600
                Re: Why don't C comments nest? Lauri Alanko <la@iki.fi> - 2011-11-12 14:29 +0000
                  Re: Why don't C comments nest? Acid Washed China Blue Jeans <chine.bleu@yahoo.com> - 2011-11-12 06:57 -0800
                  Re: Why don't C comments nest? Kaz Kylheku <kaz@kylheku.com> - 2011-11-12 17:51 +0000
                Re: Why don't C comments nest? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-12 09:44 -0500
                  Re: Why don't C comments nest? Stephen Sprunk <stephen@sprunk.org> - 2011-11-12 16:37 -0600
              Re: Why don't C comments nest? Kenneth Brody <kenbrody@spamcop.net> - 2011-11-15 14:22 -0500
                Re: Why don't C comments nest? Ian Collins <ian-news@hotmail.com> - 2011-11-16 08:41 +1300
                  Re: Why don't C comments nest? James Kuyper <jameskuyper@verizon.net> - 2011-11-15 14:48 -0500
                    Re: Why don't C comments nest? Ian Collins <ian-news@hotmail.com> - 2011-11-16 09:03 +1300
                  Re: Why don't C comments nest? "BartC" <bc@freeuk.com> - 2011-11-15 20:37 +0000
                    Re: Why don't C comments nest? Ian Collins <ian-news@hotmail.com> - 2011-11-16 10:06 +1300
                    Re: Why don't C comments nest? Keith Thompson <kst-u@mib.org> - 2011-11-15 14:31 -0800
                      Re: Why don't C comments nest? "BartC" <bc@freeuk.com> - 2011-11-15 22:41 +0000
                    Re: Why don't C comments nest? Kaz Kylheku <kaz@kylheku.com> - 2011-11-15 23:06 +0000
                      Re: Why don't C comments nest? "BartC" <bc@freeuk.com> - 2011-11-15 23:58 +0000
                        Re: Why don't C comments nest? Kaz Kylheku <kaz@kylheku.com> - 2011-11-16 01:58 +0000
                  Re: Why don't C comments nest? Willem <willem@toad.stack.nl> - 2011-11-15 22:40 +0000
                    Re: Why don't C comments nest? Ian Collins <ian-news@hotmail.com> - 2011-11-16 11:48 +1300
                    Re: Why don't C comments nest? Kaz Kylheku <kaz@kylheku.com> - 2011-11-15 23:13 +0000
                  Re: Why don't C comments nest? Kenneth Brody <kenbrody@spamcop.net> - 2011-11-16 12:57 -0500
                    Re: Why don't C comments nest? Ian Collins <ian-news@hotmail.com> - 2011-11-17 07:42 +1300
                      Re: Why don't C comments nest? John Gordon <gordon@panix.com> - 2011-11-16 18:57 +0000
                        Re: Why don't C comments nest? Ian Collins <ian-news@hotmail.com> - 2011-11-17 08:48 +1300
                          Re: Why don't C comments nest? Keith Thompson <kst-u@mib.org> - 2011-11-16 11:50 -0800
                            Re: Why don't C comments nest? Ian Collins <ian-news@hotmail.com> - 2011-11-17 09:00 +1300
                            Re: Why don't C comments nest? Kaz Kylheku <kaz@kylheku.com> - 2011-11-16 20:20 +0000
                      Re: Why don't C comments nest? blp@cs.stanford.edu (Ben Pfaff) - 2011-11-16 11:57 -0800
                        Re: Why don't C comments nest? Ian Collins <ian-news@hotmail.com> - 2011-11-17 09:47 +1300
                    Re: Why don't C comments nest? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-18 15:49 +0200
                      Re: Why don't C comments nest? James Kuyper <jameskuyper@verizon.net> - 2011-11-18 10:15 -0500
                        Re: Why don't C comments nest? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-18 17:57 +0200
          Re: Why don't C comments nest? "BartC" <bc@freeuk.com> - 2011-11-11 22:14 +0000
            Re: Why don't C comments nest? blp@cs.stanford.edu (Ben Pfaff) - 2011-11-11 14:35 -0800
              Re: Why don't C comments nest? "BartC" <bc@freeuk.com> - 2011-11-12 00:10 +0000
            Re: Why don't C comments nest? Keith Thompson <kst-u@mib.org> - 2011-11-11 15:14 -0800
              Re: Why don't C comments nest? "BartC" <bc@freeuk.com> - 2011-11-12 00:37 +0000
            Re: Why don't C comments nest? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-11 20:21 -0500
              Re: Why don't C comments nest? "BartC" <bc@freeuk.com> - 2011-11-12 11:10 +0000
                Re: Why don't C comments nest? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-12 08:11 -0500
                  Re: Why don't C comments nest? "BartC" <bc@freeuk.com> - 2011-11-12 13:57 +0000
                    Re: Why don't C comments nest? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-12 09:34 -0500
                      Re: Why don't C comments nest? "BartC" <bc@freeuk.com> - 2011-11-12 18:17 +0000
                        Re: Why don't C comments nest? Robert Wessel <robertwessel2@yahoo.com> - 2011-11-12 14:09 -0600
                          Re: Why don't C comments nest? "BartC" <bc@freeuk.com> - 2011-11-12 20:49 +0000
                            Re: Why don't C comments nest? Keith Thompson <kst-u@mib.org> - 2011-11-12 13:42 -0800
                              Re: Why don't C comments nest? "BartC" <bc@freeuk.com> - 2011-11-12 21:53 +0000
                            Re: Why don't C comments nest? Kaz Kylheku <kaz@kylheku.com> - 2011-11-12 21:44 +0000
                              Re: Why don't C comments nest? "BartC" <bc@freeuk.com> - 2011-11-12 22:12 +0000
                                Re: Why don't C comments nest? Ian Collins <ian-news@hotmail.com> - 2011-11-13 11:22 +1300
                                Re: Why don't C comments nest? Keith Thompson <kst-u@mib.org> - 2011-11-12 16:32 -0800
                        Re: Why don't C comments nest? Keith Thompson <kst-u@mib.org> - 2011-11-12 13:09 -0800
                          Re: Why don't C comments nest? "BartC" <bc@freeuk.com> - 2011-11-12 21:46 +0000
                        Re: Why don't C comments nest? Seebs <usenet-nospam@seebs.net> - 2011-11-12 21:40 +0000
        Re: Why don't C comments nest? Ian Collins <ian-news@hotmail.com> - 2011-11-12 11:20 +1300
        Re: Why don't C comments nest? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-12 00:40 +0200
        Re: Why don't C comments nest? Kaz Kylheku <kaz@kylheku.com> - 2011-11-12 04:29 +0000
          Re: Why don't C comments nest? "BartC" <bc@freeuk.com> - 2011-11-12 10:54 +0000
            Re: Why don't C comments nest? Ian Collins <ian-news@hotmail.com> - 2011-11-13 09:11 +1300
              Re: Why don't C comments nest? "BartC" <bc@freeuk.com> - 2011-11-12 20:52 +0000
                Re: Why don't C comments nest? Ian Collins <ian-news@hotmail.com> - 2011-11-13 10:22 +1300
                Re: Why don't C comments nest? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-13 23:55 +0200
          Re: Why don't C comments nest? Acid Washed China Blue Jeans <chine.bleu@yahoo.com> - 2011-11-12 07:02 -0800
            Re: Why don't C comments nest? Keith Thompson <kst-u@mib.org> - 2011-11-12 13:13 -0800
              Re: Why don't C comments nest? Acid Washed China Blue Jeans <chine.bleu@yahoo.com> - 2011-11-12 13:48 -0800
    Re: Why don't C comments nest? Acid Washed China Blue Jeans <chine.bleu@yahoo.com> - 2011-11-11 16:51 -0800
    Re: Why don't C comments nest? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-12 22:55 +0000
    Re: Why don't C comments nest? Kenneth Brody <kenbrody@spamcop.net> - 2011-11-15 14:17 -0500

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#13195

On Sat, 12 Nov 2011 18:17:36 -0000, "BartC" <bc@freeuk.com> wrote:

>"Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message 
>news:j9m058$sil$1@dont-email.me...
>> On 11/12/2011 8:57 AM, BartC wrote:
>
>>> And as things are now, we must disallow comments like my example.
>>>
>>> I can't see why one is any worse than the other.
>>
>>     Would you like to be able to use a contraction like
>>
>> if (p < endp)  /* don't run off the end! */
>
>(I still don't see what the problem would be with this example; what's 
>supposed to happen when that line in enclosed in another /*...*/ comment?)


The problem in this case is that everything starting with the
apostrophe is the (start) of a character constant, thus if you've
tokenized that by the normal C rules, the */ will be lost as part of
the contents of the character constant.  (In order to be valid
lexically, you'll need a closing apostrophe someplace).  Of course you
cannot use just any arbitrary string in a character constant, but
that's validated after it's been tokenized.


>> in a comment?  Then you    don't   want comments that nest.
>>
>>     Comments are not for suppressing blocks of code; comments are
>> for commentary.
>
>Nevertheless that's what the OP wants to do. Does the Standard specifically 
>tell us what content is allowed in a comment, and what is frowned upon?


Yes, the second sentence of the following covers it:

"6.4.9 Comments
Except within a character constant, a string literal, or a comment,
the characters /* introduce a comment. The contents of such a comment
are examined only to identify multibyte characters and to find the
characters */ that terminate it."

[toc] | [prev] | [next] | [standalone]

#13197

"Robert Wessel" <robertwessel2@yahoo.com> wrote in message
news:r7ktb7ddbpsld0uac0sv1daki6cagv9jk1@4ax.com...
> On Sat, 12 Nov 2011 18:17:36 -0000, "BartC" <bc@freeuk.com> wrote:
>
>>"Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message

>>> if (p < endp)  /* don't run off the end! */
>>
>>(I still don't see what the problem would be with this example; what's
>>supposed to happen when that line in enclosed in another /*...*/ comment?)
>
> The problem in this case is that everything starting with the
> apostrophe is the (start) of a character constant, thus if you've
> tokenized that by the normal C rules, the */ will be lost as part of
> the contents of the character constant.

OK. So the assumption is that a nested comment would tokenise it's contents.

However I don't think that's necessary. And wouldn't work anyway.

>>>     Comments are not for suppressing blocks of code; comments are
>>> for commentary.
>>
>>Nevertheless that's what the OP wants to do. Does the Standard
>>specifically
>>tell us what content is allowed in a comment, and what is frowned upon?
>
>
> Yes, the second sentence of the following covers it:
>
> "6.4.9 Comments
> Except within a character constant, a string literal, or a comment,
> the characters /* introduce a comment. The contents of such a comment
> are examined only to identify multibyte characters and to find the
> characters */ that terminate it."

In other words, anything is allowed, including source code, of C or anything
else.

So the suggestion that comments shouldn't contain source code is a style
issue that shouldn't be the concern of the Standard or imposed by a
compiler.

And reading in-between the lines, everything is allowed except */, even if
the latter was inside a literal, or inside a //-comment.

The only thing needed to make nested comments possible, is to disallow /* as
well as */, unless they are there to start or terminate a comment.

That means you won't be able to have /* as part of comment text, whether by
itself or part of a literal;  is that really that big a deal?

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#13203

"BartC" <bc@freeuk.com> writes:
[...]
> OK. So the assumption is that a nested comment would tokenise it's contents.
>
> However I don't think that's necessary. And wouldn't work anyway.

[big snip]

> That means you won't be able to have /* as part of comment text, whether by
> itself or part of a literal;  is that really that big a deal?

It would break existing code.

If you're advocating a change to the C language, the fact that it
would break existing code means such a change will not be adopted.

If you're talking about a C-like language in which comments nest,
then you're not talking about C.

Which is it?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#13209

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnhb29587q.fsf@nuthaus.mib.org...
> "BartC" <bc@freeuk.com> writes:

>> That means you won't be able to have /* as part of comment text, whether 
>> by
>> itself or part of a literal;  is that really that big a deal?
>
> It would break existing code.
>
> If you're advocating a change to the C language, the fact that it
> would break existing code means such a change will not be adopted.
>
> If you're talking about a C-like language in which comments nest,
> then you're not talking about C.
>
> Which is it?

Sorry, I thought this part of the thread was about hard or how practical it 
would be to make /*...*/ nestable.

Like the OP I also think this is desirable (and at one time thought they 
*were* nestable, then found it didn't work!)

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#13204

On 2011-11-12, BartC <bc@freeuk.com> wrote:
> "Robert Wessel" <robertwessel2@yahoo.com> wrote in message
>> "6.4.9 Comments
>> Except within a character constant, a string literal, or a comment,
>> the characters /* introduce a comment. The contents of such a comment
>> are examined only to identify multibyte characters and to find the
>> characters */ that terminate it."
>
> In other words, anything is allowed, including source code, of C or anything
> else.

No, because the formal language allowed within the comment excludes the
digraph */ which may occur in the source code of C, inside a string
literal, as part of a comment, or inside a // comment.

> So the suggestion that comments shouldn't contain source code is a style
> issue that shouldn't be the concern of the Standard or imposed by a
> compiler.

It's more than a style issue; it's a formal language issue. Comments can only
contain a subset of the possible set of C strings.

It is useful that you can have a subset of C within comments, for instance,
coding examples. They just can't have /*...*/ comments of their own, which is
fine since they are already inside a comment which can explain everything.

A mechanism for commenting out arbitrary code must be robust, period. This way
it can be applied to a 50,000 line piece of source code without worry that
anything breaks. 

#if 0 ... #endif  satisfies that requirement. 

For excluding small ranges of text not confined entire lines,
a variadic macro which expands to nothing works great:

  #define IG(...) 
  IG(abitrary * preprocessor, ++t 0kens)

Therefore, it is no longer necessary to entertain proposals about nested
comments.

[toc] | [prev] | [next] | [standalone]

#13210

"Kaz Kylheku" <kaz@kylheku.com> wrote in message
news:20111112133440.675@kylheku.com...
> On 2011-11-12, BartC <bc@freeuk.com> wrote:

>> In other words, anything is allowed, including source code, of C or
>> anything
>> else.
>
> No, because the formal language allowed within the comment excludes the
> digraph */ which may occur in the source code of C, inside a string
> literal, as part of a comment, or inside a // comment.

Well, yes; I mentioned */ a sentence or two later.

> It's more than a style issue; it's a formal language issue. Comments can
> only
> contain a subset of the possible set of C strings.
>
> It is useful that you can have a subset of C within comments, for
> instance,
> coding examples. They just can't have /*...*/ comments of their own, which
> is
> fine since they are already inside a comment which can explain everything.

What you're saying then is that /*...*/ comments are not a suitable
mechanism for commenting out code? The reason being that code might contain
(in perhaps one program in a thousand) a '*/' or "*/" token? Yet everyone
does this, and the world hasn't yet ended.

And perhaps /*...*/ isn't suitable for writing comments, period, since there
will from time to time be content that will break it. For example I couldn't
paste */this sentence/* into such a comment. Yet that doesn't bother many
people either.

> A mechanism for commenting out arbitrary code must be robust, period. This
> way
> it can be applied to a 50,000 line piece of source code without worry that
> anything breaks.
>
> #if 0 ... #endif  satisfies that requirement.

Only if the code you're trying to 'comment out' is well-formed. If it's
unfinished, has open literals, and unbalanced #endifs scattered about, then
there will be problems. In this case /*...*/ might be a better bet...

-- 
bartc 

[toc] | [prev] | [next] | [standalone]

#13211

On 11/13/11 11:12 AM, BartC wrote:
> "Kaz Kylheku"<kaz@kylheku.com>  wrote;
>
>> A mechanism for commenting out arbitrary code must be robust, period. This
>> way
>> it can be applied to a 50,000 line piece of source code without worry that
>> anything breaks.
>>
>> #if 0 ... #endif  satisfies that requirement.
>
> Only if the code you're trying to 'comment out' is well-formed. If it's
> unfinished, has open literals, and unbalanced #endifs scattered about, then
> there will be problems. In this case /*...*/ might be a better bet...

That's a process problem, not a language one!  Such "stuff" shouldn't 
exist in code.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#13219

"BartC" <bc@freeuk.com> writes:
[...]
> What you're saying then is that /*...*/ comments are not a suitable
> mechanism for commenting out code? The reason being that code might contain
> (in perhaps one program in a thousand) a '*/' or "*/" token? Yet everyone
> does this, and the world hasn't yet ended.

/*...*/ comments are not a suitable mechanism for commenting out code
because code often includes its own /*...*/ comments, and they don't
nest.

Most of the issues involving '*/' or "*/" tokens don't even arise until
you start talking about changing the language to allow /*...*/ comments
to nest, and any such change would break existing code.

It's been mentioned several times that changing the language to allow
/*...*/ comments to nest would break existing code.  If you've ever
acknowledged that very important point, I've missed it.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#13199

"BartC" <bc@freeuk.com> writes:
> "Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message 
> news:j9m058$sil$1@dont-email.me...
>> On 11/12/2011 8:57 AM, BartC wrote:
>
>>> And as things are now, we must disallow comments like my example.
>>>
>>> I can't see why one is any worse than the other.
>>
>>     Would you like to be able to use a contraction like
>>
>> if (p < endp)  /* don't run off the end! */
>
> (I still don't see what the problem would be with this example; what's 
> supposed to happen when that line in enclosed in another /*...*/ comment?)

Currently, /*...*/ comments don't nest.  As a result, once the
compiler sees a /* sequence that's not inside another token (a string
literal or, rarely, a character constant), it only needs to scan
for a */ sequence, regardless of the context in which it appears.

With nesting comments, after seeing an opening /*, there are several
possible approaches:

1. Scan for /* and */ without tokenization and keep a count of the
nesting level.  This causes problems if a comment contains a string
literal containing /* or */:

    /* const char open_comment[] = "/*"; */

The */ at the end of the line terminates the inner comment, not the
outer one.  Presumably the idea of allowing nested comments is to
make it possible to use /* and */ to comment out a chunk of code
that itself contains /*...*/ comments, but this example shows that
that still wouldn't work in all cases.

2. Tokenize everything inside /*...*/ comments, so that the compiler
can detect cases like the above and ignore comment delimiters in
commented-out string literals.  But this comment from Eric's post:

    if (p < endp)  /* don't run off the end! */

doesn't contain a valid token sequence.

3. Define a new set of tokenization rules for use inside comments,
so that comment delimiters within string literals within comments
are ignored, but arbitrary text that doesn't necesssarily form a
valid token sequence is accepted.  Note that '"' and '*/' are valid
character constants.  Since the content of a comment may or may not
be some approximation of C source code, it's difficult to decide
whether a given sequence of characters that happens to include
double-quote charactes should be treated as a C string literal
or not.

And of course *any* of these changes would break existing code,
which means the odd of any of them being adopted are close to zero.

>> in a comment?  Then you    don't   want comments that nest.
>>
>>     Comments are not for suppressing blocks of code; comments are
>> for commentary.
>
> Nevertheless that's what the OP wants to do. Does the Standard specifically 
> tell us what content is allowed in a comment, and what is frowned upon?

Not directly, no.  But it does clearly say that /*...*/ comments don't
nest, from which one can easily infer that you can't use /*...*/ to
comment out a block of code that already contains /*...*/ comments.

And if you want to comment out a block of code, you can always insert
a // at the beginning of each line.  This makes it easier to see
at a glance which lines are commented out and avoids all the above
problems.  (It does require you to have a compiler that recognizes //
comments, which is an issue if you want to use strict C90 or C95 mode.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#13205

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnty6959q3.fsf@nuthaus.mib.org...
> "BartC" <bc@freeuk.com> writes:
>> "Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message

>>> if (p < endp)  /* don't run off the end! */
>>
>> (I still don't see what the problem would be with this example; what's
>> supposed to happen when that line in enclosed in another /*...*/
>> comment?)
>
> Currently, /*...*/ comments don't nest.  As a result, once the
> compiler sees a /* sequence that's not inside another token (a string
> literal or, rarely, a character constant), it only needs to scan
> for a */ sequence, regardless of the context in which it appears.
>
> With nesting comments, after seeing an opening /*, there are several
> possible approaches:
>
> 1. Scan for /* and */ without tokenization and keep a count of the
> nesting level.  This causes problems if a comment contains a string
> literal containing /* or */:
>
>    /* const char open_comment[] = "/*"; */

Option (1) I think is the only viable one. And yes it does have a cost in
that spurious /* sequences are no longer allowed. But then /neither were
spurious */ sequences/!

What have people done in the past when */ was needed inside  a /*...*/ 
comment? Whatever they did, perhaps they can do the same for /*!

> 2. Tokenize everything inside /*...*/ comments, so that the compiler
...
> 3. Define a new set of tokenization rules for use inside comments,
> so that comment delimiters within string literals within comments
> are ignored, but arbitrary text that doesn't necesssarily form a
> valid token sequence is accepted.

Those won't work because comments should be allowed to be anything at all;
you shouldn't have to write comments to conform to a syntax! So they might
be in badly written and punctuated language, or be badly written, incorrect
and incomplete source code, or metadata for all sorts of purposes.

The only restriction is that */ can't be included, and, for nested comments, 
neither can /*.

>  Note that '"' and '*/' are valid
> character constants.

'*/' is valid by itself, but not inside /*...*/ comment, where it will 
generate a syntax error.

> And of course *any* of these changes would break existing code,
> which means the odd of any of them being adopted are close to zero.

Possibly. Checking code for /* sequences inside comments doesn't sound
difficult. But once nested comments are in use, they won't be backwards
incompatible.

-- 
bartc 

[toc] | [prev] | [next] | [standalone]

#13208

On 2011-11-12, BartC <bc@freeuk.com> wrote:
> "Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message 
> news:j9m058$sil$1@dont-email.me...
>>     Would you like to be able to use a contraction like

>> if (p < endp)  /* don't run off the end! */

> (I still don't see what the problem would be with this example; what's 
> supposed to happen when that line in enclosed in another /*...*/ comment?)

Consider, if you will:

	char *start_comment = "/*";

If comments don't nest, this is NEVER a problem.  If comments nest, though,
this becomes a problem.  The only way to get around that is to parse the
things inside a comment to see whether they really ought to be starting
a nested comment.  But if we're parsing things inside comments:

	/* don't run off the end! */

becomes a problem because it has a mismatched single quote.

Similarly, right now:

	char *end_comment = "*/";

is fine, as long as you don't try to comment it out.  Which is to say:

Comments should be text, not code, and comments are not the right tool
for cutting out bits of code.  #if 0 is the right tool for cutting out bits
of code, because it works in terms of code.  Comments used for code induce
serious problems.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#13133

On 11/12/11 09:28 AM, BartC wrote:
> "Kaz Kylheku"<kaz@kylheku.com>  wrote:
>
>> The upshot is that /* */ is for writing comments and #if ... #endif
>> is for "compiling out" code you don't want.
>
> Suppose the code you want to comment out is the middle of a line, which is
> already using /*...*/ ?

Check in, remove code, compile, test and if required, revert.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#13144

"BartC" <bc@freeuk.com> writes:

> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
> news:20111111115530.783@kylheku.com...
> > On 2011-11-11, Aron Packer <atp1@rightthing.invalid> wrote:
> >> Hi all,
> >>
> >> (Apologies if this is in a FAQ somewhere, I couldn't find anything).
> >>
> >> Almost every time I do any significant amount of coding in C or C++, I
> >> end up wishing C-style comments would nest. It would make rapid
> >> debugging much more convenient (vs. #if 0/#endif or editor macros).
> >
> > Rapid meaning, what you save a few keystrokes over #if 0?
> >
> >> Anyway, was this an explicit design decision, or some sort of historical
> >> artifact? (e.g. too expensive to parse at the time). What other sorts of
> >> reasons might exist against nesting comments?
> >
> > Consideration 1:
> >
> > In order for comments  to be suitable as a feature for commenting out
> > code,
> > the language has to be defined differently. Firstly, /* and */ have to be
> > tokens.  Secondly, the "commented out" material between the /* and */
> > tokens has
> > to also be delimited into tokens.
> 
> I don't think that's necessary, but you have to consider that */ inside a
> string literal, or as part of a // comment, may cause problems.
> 
> > This way, for instance, the following will not break:
> >
> > /* char *comment_end = "/*";  */
> 
> > Here,  "/*" is embedded in a string literal token and so loses
> > the comment-closing meaning.
> 
> You mean "*/"? In which case you can't even write it whether you have nested
> comments or not:

That example wouldn't demonstrate nesting. I prefer the "/*" example, 
as, with nesting, you can't use the final */ to close the comment, only 
to decrease its comment nesting to 1.

Phil
-- 
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

[toc] | [prev] | [next] | [standalone]

#13166

On 2011-11-11, BartC <bc@freeuk.com> wrote:
> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
>> This way, for instance, the following will not break:
>>
>> /* char *comment_end = "/*";  */
>
>> Here,  "/*" is embedded in a string literal token and so loses
>> the comment-closing meaning.
>
> You mean "*/"? In which case you can't even write it whether you have nested
> comments or not:

That's my point. You can't write it without nested comments, but nested
comments don't fix anything.

>> Note that if you allow only tokens between /* and */, then it becomes
>> more difficult to write comments, which cannot be freeform text.
>>
>> The #if 0 directive solves the embedding problem, because material which
>> is
>
> Perhaps have #comment ... #end then

That's a useless syntactic sugar for #if 0; furthermore, it's badly
named since this feature is not for commenting. Your "comment" has
to be written in valid C preprocessor tokens.

Really, do you need to be able to invoke undefined behavior in comments? :)

> Suppose the code you want to comment out is the middle of a line, which is
> already using /*...*/ ?

There is this:

C89:

   #define IGN(X)

   IGN( foo() );

   void bar(IGN( const ) int *ptr)
   {
   }

Now, an unparenthesized comma doesn't work, e,g. IGN(A, B).

C99 varidic macros to the rescue:

   #define IGN(...)

   struct x y = { 1, 2 IGN( , 3, 4 ) };

Or you could just edit the darn code. Remove the inner /* */ and add the outer
ones. There are few enough people working in C, and out of those few enough who
have this problem, that it's not some kind of wide-spread economic problem.

[toc] | [prev] | [next] | [standalone]

#13175

"Kaz Kylheku" <kaz@kylheku.com> wrote in message 
news:20111111201323.325@kylheku.com...
> On 2011-11-11, BartC <bc@freeuk.com> wrote:

>> Perhaps have #comment ... #end then
>
> That's a useless syntactic sugar for #if 0; furthermore, it's badly
> named since this feature is not for commenting. Your "comment" has
> to be written in valid C preprocessor tokens.

That was before I realised that #if 0 didn't work as I expected, ie. ignore 
everything except what was necessary to find a matching #endif.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#13196

On 11/12/11 11:54 PM, BartC wrote:
> "Kaz Kylheku"<kaz@kylheku.com>  wrote in message
> news:20111111201323.325@kylheku.com...
>> On 2011-11-11, BartC<bc@freeuk.com>  wrote:
>
>>> Perhaps have #comment ... #end then
>>
>> That's a useless syntactic sugar for #if 0; furthermore, it's badly
>> named since this feature is not for commenting. Your "comment" has
>> to be written in valid C preprocessor tokens.
>
> That was before I realised that #if 0 didn't work as I expected, ie. ignore
> everything except what was necessary to find a matching #endif.

Removing the code works as expected.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#13198

"Ian Collins" <ian-news@hotmail.com> wrote in message
news:9i828hFk4oU2@mid.individual.net...
> On 11/12/11 11:54 PM, BartC wrote:
>> "Kaz Kylheku"<kaz@kylheku.com>  wrote in message
>> news:20111111201323.325@kylheku.com...
>>> On 2011-11-11, BartC<bc@freeuk.com>  wrote:
>>
>>>> Perhaps have #comment ... #end then
>>>
>>> That's a useless syntactic sugar for #if 0; furthermore, it's badly
>>> named since this feature is not for commenting. Your "comment" has
>>> to be written in valid C preprocessor tokens.
>>
>> That was before I realised that #if 0 didn't work as I expected, ie.
>> ignore
>> everything except what was necessary to find a matching #endif.
>
> Removing the code works as expected.

That's rather a drastic measure. Especially if you've just downloaded some
source code and big chunks of it have been cut out! Rather difficult to
reinstate then. Anyway suppose the commented lines are actually intended to 
be read?

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#13202

On 11/13/11 09:52 AM, BartC wrote:
>
>
> "Ian Collins"<ian-news@hotmail.com>  wrote in message
> news:9i828hFk4oU2@mid.individual.net...
>> On 11/12/11 11:54 PM, BartC wrote:
>>> "Kaz Kylheku"<kaz@kylheku.com>   wrote in message
>>> news:20111111201323.325@kylheku.com...
>>>> On 2011-11-11, BartC<bc@freeuk.com>   wrote:
>>>
>>>>> Perhaps have #comment ... #end then
>>>>
>>>> That's a useless syntactic sugar for #if 0; furthermore, it's badly
>>>> named since this feature is not for commenting. Your "comment" has
>>>> to be written in valid C preprocessor tokens.
>>>
>>> That was before I realised that #if 0 didn't work as I expected, ie.
>>> ignore
>>> everything except what was necessary to find a matching #endif.
>>
>> Removing the code works as expected.
>
> That's rather a drastic measure. Especially if you've just downloaded some
> source code and big chunks of it have been cut out!

But why would they have been cut out if they were required?  Blocks of 
code usually get commented out during development and this can be 
managed by version control, or an IDE.

> Rather difficult to
> reinstate then. Anyway suppose the commented lines are actually intended to
> be read?

They could be commented out with //

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#13257

"BartC" <bc@freeuk.com> writes:
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:9i828hFk4oU2@mid.individual.net...
> > On 11/12/11 11:54 PM, BartC wrote:
> >> "Kaz Kylheku"<kaz@kylheku.com>  wrote in message
> >> news:20111111201323.325@kylheku.com...
> >>> On 2011-11-11, BartC<bc@freeuk.com>  wrote:
> >>
> >>>> Perhaps have #comment ... #end then
> >>>
> >>> That's a useless syntactic sugar for #if 0; furthermore, it's badly
> >>> named since this feature is not for commenting. Your "comment" has
> >>> to be written in valid C preprocessor tokens.
> >>
> >> That was before I realised that #if 0 didn't work as I expected, ie.
> >> ignore
> >> everything except what was necessary to find a matching #endif.
> >
> > Removing the code works as expected.
> 
> That's rather a drastic measure. Especially if you've just downloaded some
> source code and big chunks of it have been cut out! Rather difficult to
> reinstate then.

For values of 'difficult' almost indistinguishable from 'trivial'

$ git reset --hard HEAD

> Anyway suppose the commented lines are actually intended to be read?

"The" commented lines? Which commented lines? Your hypothetical is
purely in your own head currently. It's hard to suggest solutions to
problems unless they're unambiguously described. If there's no reason
to change the code you've been given, and it's valid code - then just
leave it alone. That's not, however, any justification for creating
new code that contains evidence of sloppy development practices.

Phil
-- 
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

[toc] | [prev] | [next] | [standalone]

#13186

In article <20111111201323.325@kylheku.com>, Kaz Kylheku <kaz@kylheku.com> 
wrote:

> > Suppose the code you want to comment out is the middle of a line, which is
> > already using /*...*/ ?
> 
> There is this:
> 
> C89:
> 
>    #define IGN(X)
> 
>    IGN( foo() );
> 
>    void bar(IGN( const ) int *ptr)
>    {
>    }
> 
> Now, an unparenthesized comma doesn't work, e,g. IGN(A, B).

I just select the comment text and switch the font from Helvetica to Palatino. 
That way I can embed whatever comments I want without all these distracting /* 
*/ //.

-- 
White folks think they're at the top,  |   Faded, patched, secret so tight...
ask any proud white male.              |       I'm whoever you want me to be.
A million years of evolution,          |  Annoying Usenet one post at a time.
and we get Danny Quayle.               |    At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web