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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#13504

On 11/17/11 07:57 AM, John Gordon wrote:
> In<9iieguFi5oU10@mid.individual.net>  Ian Collins<ian-news@hotmail.com>  writes:
>
>> As I said yesterday, you don't have to resort to such an awful layout to
>> accommodate conditional compilation:
>
>> #if INCLUDE_DEBUG_INFO
>>     some_function( 10, 20, __FILE__, __LINE__ );
>> #else
>>     some_function( 10, 20 );
>> #endif
>
> This violates the DRY principle.  What happens when you (or a future
> maintainer) change the value of an argument in the first call but neglect
> to change it in the second call?

The relevant tests will fail and the code will be fixed.

-- 
Ian Collins

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

#13506

Ian Collins <ian-news@hotmail.com> writes:
> On 11/17/11 07:57 AM, John Gordon wrote:
>> In<9iieguFi5oU10@mid.individual.net>  Ian Collins<ian-news@hotmail.com>  writes:
>>
>>> As I said yesterday, you don't have to resort to such an awful layout to
>>> accommodate conditional compilation:
>>
>>> #if INCLUDE_DEBUG_INFO
>>>     some_function( 10, 20, __FILE__, __LINE__ );
>>> #else
>>>     some_function( 10, 20 );
>>> #endif
>>
>> This violates the DRY principle.  What happens when you (or a future
>> maintainer) change the value of an argument in the first call but neglect
>> to change it in the second call?
>
> The relevant tests will fail and the code will be fixed.

Even with perfect test coverage, you've just spent time fixing a bug
(and tracking down the cause) that wouldn't ever have occurred if
you'd written "10, 20" only once.

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

#13509

On 11/17/11 08:50 AM, Keith Thompson wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>> On 11/17/11 07:57 AM, John Gordon wrote:
>>> In<9iieguFi5oU10@mid.individual.net>   Ian Collins<ian-news@hotmail.com>   writes:
>>>
>>>> As I said yesterday, you don't have to resort to such an awful layout to
>>>> accommodate conditional compilation:
>>>
>>>> #if INCLUDE_DEBUG_INFO
>>>>      some_function( 10, 20, __FILE__, __LINE__ );
>>>> #else
>>>>      some_function( 10, 20 );
>>>> #endif
>>>
>>> This violates the DRY principle.  What happens when you (or a future
>>> maintainer) change the value of an argument in the first call but neglect
>>> to change it in the second call?
>>
>> The relevant tests will fail and the code will be fixed.
>
> Even with perfect test coverage, you've just spent time fixing a bug
> (and tracking down the cause) that wouldn't ever have occurred if
> you'd written "10, 20" only once.

The original example was fairly trivial; imagine the case where the 
parameter order changed, or there are more than two possibilities.

I have an application that works with several version of an unofficial 
system library.  To date there have been 4 changes to the parameters for 
one function....

-- 
Ian Collins

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

#13515

On 2011-11-16, Keith Thompson <kst-u@mib.org> wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> On 11/17/11 07:57 AM, John Gordon wrote:
>>> In<9iieguFi5oU10@mid.individual.net>  Ian Collins<ian-news@hotmail.com>  writes:
>>>
>>>> As I said yesterday, you don't have to resort to such an awful layout to
>>>> accommodate conditional compilation:
>>>
>>>> #if INCLUDE_DEBUG_INFO
>>>>     some_function( 10, 20, __FILE__, __LINE__ );
>>>> #else
>>>>     some_function( 10, 20 );
>>>> #endif
>>>
>>> This violates the DRY principle.  What happens when you (or a future
>>> maintainer) change the value of an argument in the first call but neglect
>>> to change it in the second call?
>>
>> The relevant tests will fail and the code will be fixed.
>
> Even with perfect test coverage, you've just spent time fixing a bug
> (and tracking down the cause) that wouldn't ever have occurred if
> you'd written "10, 20" only once.

Also this bug will occur either in the build with debug info or the one
without.

The perfect test coverage has to be repeated for both builds of the program.

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

#13510

Ian Collins <ian-news@hotmail.com> writes:

> As I said yesterday, you don't have to resort to such an awful layout
> to accommodate conditional compilation:
>
> #if INCLUDE_DEBUG_INFO
>   some_function( 10, 20, __FILE__, __LINE__ );
> #else
>   some_function( 10, 20 );
> #endif

#ifdef INCLUDE_DEBUG_INFO
#define somefunction(a, b) somefunction(a, b, __FILE__, __LINE__)
#endif
-- 
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

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

#13518

On 11/17/11 08:57 AM, Ben Pfaff wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>
>> As I said yesterday, you don't have to resort to such an awful layout
>> to accommodate conditional compilation:
>>
>> #if INCLUDE_DEBUG_INFO
>>    some_function( 10, 20, __FILE__, __LINE__ );
>> #else
>>    some_function( 10, 20 );
>> #endif
>
> #ifdef INCLUDE_DEBUG_INFO
> #define somefunction(a, b) somefunction(a, b, __FILE__, __LINE__)
> #endif

Yes, there are many ways to skin that particular cat!

My objection to the earlier proposals was more than just the awful 
style: it falls apart for all but the most trivial examples.

-- 
Ian Collins

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

#13591

Kenneth Brody <kenbrody@spamcop.net> writes:
> On 11/15/2011 2:41 PM, Ian Collins wrote:
> > On 11/16/11 08:22 AM, Kenneth Brody wrote:
> [...]
> >> In such cases, I often use:
> >>
> >> some_function( 10 /* param1 */
> >> ,20 /* param2 */
> >> #if 0
> >> ,30 /* param3 */
> >> #endif
> >> );
> >>
> >> A little awkward, but "less ugly".
> >
> > I still don't understand you anyone would do this.
> >
> > Why not just remove the unused parameter?
> 
> Would this make you feel better?
> 
> some_function( 10 /* param1 */
>                ,20 /* param2 */
> #if INCLUDE_DEBUG_INFO
>                ,__FILE__
>                ,__LINE__
> #endif
>               );

A few years while I was complifying some code, I added some 
extra parameters to many functions that I found I wasn't really
using. The way I did it was something like the following (grab 
a bucket...)

#if HAVE_EXTRA_CRAP
# define EXTRA_PARAMS(p1,p2) , float p1, float p2
# define EXTRA_ARGS(p1,p2) , p1, p2
#else
# define EXTRA_PARAMS(p1,p2) /* no extra parameters */
# define EXTRA_ARGS(p1,p2) /* no extra arguments */
#endif

int some_caller(int foo  EXTRA_PARAMS(mini, maxi))
{
  return some_function(foo-1  EXTRA_ARGS(mini, maxi))
}

I do wish the 'trailing comma' had wider acceptance, as it 
would make the above less barfworthy.

Fortunately, there's a happy ending. I saw the error of my 
ways, and just removed all the extra stuff I no longer wanted
to use, and I have to dig into the version control system if
I ever want to see it again.

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

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

#13598

On 11/18/2011 08:49 AM, Phil Carmody wrote:
...
> A few years while I was complifying some code, I added some 

You don't always have to coin a new word. Try "complicating".

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

#13600

James Kuyper <jameskuyper@verizon.net> writes:
> On 11/18/2011 08:49 AM, Phil Carmody wrote:
> ...
> > A few years while I was complifying some code, I added some 
> 
> You don't always have to coin a new word. Try "complicating".

You don't understand - the use of the extra parameters was to *simplify* things!

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

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

#13132

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnobwi7421.fsf@nuthaus.mib.org...
> "BartC" <bc@freeuk.com> writes:
>> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
>> news:20111111115530.783@kylheku.com...
> [...]
>>> The #if 0 directive solves the embedding problem, because material which
>>> is
>>
>> Perhaps have #comment ... #end then

> Hmm?  What problem would #comment ... #end solve that #if 0 ... #endif
> doesn't already solve?

It's more self-explanatory than #if 0

>> Suppose the code you want to comment out is the middle of a line, which
>> is
>> already using /*...*/ ?
>
> Well then I guess you've got a bit of a problem.  But I don't think I've
> evern run into that situation.
>
> Let's see if I can come up with a plausible example.

The problem is placing unnecessary restrictions on how C code is laid out.

Insisting on #if 0 means imposing a line-oriented structure, while C is
supposed to be free-format.

Besides, any example anyone comes up with, can be rewritten to use multiple
lines that would allow the use of #if 0. If which case, why bother having 
/*...*/ comments at all?

The advantage of /*...*/ is starting and/or ending the comment in the middle
of a line. If that is desirable, why shouldn't one be able to do it on a
section of code (which could span multiple lines) which happens to already 
have a comment in there?

Maybe there are several existing comments, some can be whole lines and some
partial. Or it's a massive bit of code and it may not be easy to check
whether there are comments there or not! But it shouldn't be necessary to 
care.

-- 
Bartc 

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

#13141

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

> Besides, any example anyone comes up with, can be rewritten to use multiple
> lines that would allow the use of #if 0. If which case, why bother
> having /*...*/ comments at all?

#if 0
Because this won't compile.
#endif
-- 
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

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

#13153

"Ben Pfaff" <blp@cs.stanford.edu> wrote in message
news:874nya5ltx.fsf@blp.benpfaff.org...
> "BartC" <bc@freeuk.com> writes:
>
>> Besides, any example anyone comes up with, can be rewritten to use
>> multiple
>> lines that would allow the use of #if 0. If which case, why bother
>> having /*...*/ comments at all?
>
> #if 0
> Because this won't compile.
> #endif

OK, so lines between #if 0 and #endif are tokenised (as I found out earlier)
and need to contain well-formed char/string literals and ordinary comments,
even if it doesn't care about other tokens and about any syntax.

(Which also means it might be unusable for some kinds of multi-line
comments, where you want to temporarily comment-out a half-finished block of 
code where some tokens are not complete. Although there is the same problem 
with  enclosing the block in a /*...*/ comment when there is an open /*...*/ 
comment inside.)

I would have expected #if 0 to completely ignore any lines that didn't start
with #.

-- 
Bartc 

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

#13147

"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnobwi7421.fsf@nuthaus.mib.org...
>> "BartC" <bc@freeuk.com> writes:
>>> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
>>> news:20111111115530.783@kylheku.com...
>> [...]
>>>> The #if 0 directive solves the embedding problem, because material which
>>>> is
>>>
>>> Perhaps have #comment ... #end then
>
>> Hmm?  What problem would #comment ... #end solve that #if 0 ... #endif
>> doesn't already solve?
>
> It's more self-explanatory than #if 0

So use #ifdef SOME_MEANINGFUL_IDENTIFIER, and don't provide a definition
for that identifier.

>>> Suppose the code you want to comment out is the middle of a line, which
>>> is
>>> already using /*...*/ ?
>>
>> Well then I guess you've got a bit of a problem.  But I don't think I've
>> evern run into that situation.
>>
>> Let's see if I can come up with a plausible example.
>
> The problem is placing unnecessary restrictions on how C code is laid out.
>
> Insisting on #if 0 means imposing a line-oriented structure, while C is
> supposed to be free-format.
>
> Besides, any example anyone comes up with, can be rewritten to use multiple
> lines that would allow the use of #if 0. If which case, why bother having 
> /*...*/ comments at all?

Because /*...*/ comments are more convenient in many cases.

(Personally, I wouldn't mind having just // comments and no /*...*/
comments, but of course we can't change that now.  There are plenty of
languages that only have end-of-lime comments.)

> The advantage of /*...*/ is starting and/or ending the comment in the middle
> of a line. If that is desirable, why shouldn't one be able to do it on a
> section of code (which could span multiple lines) which happens to already 
> have a comment in there?

Because nothing is perfect, and you can't have everything.

> Maybe there are several existing comments, some can be whole lines and some
> partial. Or it's a massive bit of code and it may not be easy to check
> whether there are comments there or not! But it shouldn't be necessary to 
> care.

I have no doubt that the syntax of C comments could be tweaked in some
way that would be more to your liking.  Any such change would result in
something that's less to someone else's liking.  I don't suggest that
your preferences are less important than someone else's; the deciding
factor has to be backward compatibility.

Come up with a proposed change that (a) does what you want, and (b)
doesn't break existing code, and we can discuss it.  (But the current
system isn't sufficiently broken that any such change is likely to be
adopted.)

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

#13155

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

>> Besides, any example anyone comes up with, can be rewritten to use
>> multiple
>> lines that would allow the use of #if 0. If which case, why bother having
>> /*...*/ comments at all?
>
> Because /*...*/ comments are more convenient in many cases.
>
> (Personally, I wouldn't mind having just // comments and no /*...*/
> comments, but of course we can't change that now.  There are plenty of
> languages that only have end-of-lime comments.)

// comments aren't too bad, other than problems with imposing
line-orientation on the source code (so breaking a line inside a // comment
causes a problem, and so does joining a //-line to a non-// one).

And they behave much better with nested comments.

> I have no doubt that the syntax of C comments could be tweaked in some
> way that would be more to your liking.

Don't worry about me; I don't use C enough for it to be that important.

I'm just saying that /*...*/ can be made to nest without any serious
problems, most of the time...; no new syntax is needed.

(I've programmed nested comments for other languages, and they work fine;
mostly I used {...}, which would be problematic for C, and have experimented
with \...\ and {/.../} (which frees up { and }). However 99% of the time I
use //-like comments to end-of-line, but with a single character, such as !, 
# and \.

>  Any such change would result in
> something that's less to someone else's liking.

(Ideally you would just tell an editor to comment/uncomment some highlighted
text, and it would just do it. Nested comments are still important, and
maybe it could even fix-up any troublesome characters, such as a stray */,
that might cause a problem. In this case the actual comment syntax becomes
less critical.)

-- 
Bartc 

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

#13158

On 11/11/2011 5:14 PM, BartC wrote:
> [...]
> Besides, any example anyone comes up with, can be rewritten to use multiple
> lines that would allow the use of #if 0. If which case, why bother
> having /*...*/ comments at all?

     Because the text inside /*...*/ can be anything at all except */.

	strcat(p, "'");  /* can't use " here */

If you want comments to nest and *not* to be tripped up by examples
like Kaz' `/* char *comment_end = "/*"; */', then you need to insist
that the comment's content be lex-able, and comments like the one in
my example would become impossible.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#13176

"Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message
news:j9khmm$2qa$1@dont-email.me...
> On 11/11/2011 5:14 PM, BartC wrote:

> strcat(p, "'");  /* can't use " here */

Sorry I don't understand your point here.

> If you want comments to nest and *not* to be tripped up by examples
> like Kaz' `/* char *comment_end = "/*"; */', then you need to insist
> that the comment's content be lex-able, and comments like the one in
> my example would become impossible.

But if someone wants to write a /* ... */ comment then they will be tripped
up by anything containing a */:

// */gobbledygook/*

The above is fine (maybe they intended the comment to be bold/italic on
Usenet). Now comment out the section using /*...*/:

/*
// */gobbledygook/*
*/

Now it no longer compiles (not unless gobbledygook is a valid macro).

So /*...*/ comments are flawed whether they are nested or not. Since they
are still widely used despite this flaw, I can't see why the similarly 
flawed nested ones can't also have been in use from the start (I agree 
introducing them now might throw up a few odd errors).

-- 
Bartc 

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

#13179

On 11/12/2011 6:10 AM, BartC wrote:
>
>
> "Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message
> news:j9khmm$2qa$1@dont-email.me...
>> On 11/11/2011 5:14 PM, BartC wrote:
>
>> strcat(p, "'"); /* can't use " here */
>
> Sorry I don't understand your point here.

     See below.

>> If you want comments to nest and *not* to be tripped up by examples
>> like Kaz' `/* char *comment_end = "/*"; */', then you need to insist
>> that the comment's content be lex-able, and comments like the one in
>> my example would become impossible.
>
> But if someone wants to write a /* ... */ comment then they will be tripped
> up by anything containing a */:

     ... which Kaz' example does not.  Repeat: Kaz' example does not
contain a */ inside the comment.  Look more closely.

     His example works fine in today's C, but would get into trouble
in a C where comments nested.  Why?  Because you're on the horns of
a dilemma:

     - You can see the quoted /* as the start of a nested comment,
       causing you to interpret the */ as the end of that nested
       comment,

     or

     - You must lex the internals of the comment to recognize that
       that "/*" is a string literal and not the start of an inner
       comment.

If you take the first course, then the */ ends the internal comment
but leaves the external comment still alive, still eating all the
rest of the source file.  If you take the second, then you must
disallow comments of the kind I illustrated above, because your
lexer will trip over the unmatched ' and/or " characters.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#13180

"Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message 
news:j9lrai$mm$1@dont-email.me...
> On 11/12/2011 6:10 AM, BartC wrote:

>> But if someone wants to write a /* ... */ comment then they will be 
>> tripped
>> up by anything containing a */:
>
>     ... which Kaz' example does not.  Repeat: Kaz' example does not
> contain a */ inside the comment.  Look more closely.

Yes I know it doesn't. And I gave a counter-example which looked like this:

/* char *comment_end = "*/";  */

(which also happens to match the variable more accurately, but that's 
another matter...)

> rest of the source file.  If you take the second, then you must
> disallow comments of the kind I illustrated above, because your
> lexer will trip over the unmatched ' and/or " characters.

And as things are now, we must disallow comments like my example.

I can't see why one is any worse than the other.

-- 
Bartc 

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

#13183

On 11/12/2011 8:57 AM, BartC wrote:
> "Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message
> news:j9lrai$mm$1@dont-email.me...
>> On 11/12/2011 6:10 AM, BartC wrote:
>
>>> But if someone wants to write a /* ... */ comment then they will be
>>> tripped
>>> up by anything containing a */:
>>
>> ... which Kaz' example does not. Repeat: Kaz' example does not
>> contain a */ inside the comment. Look more closely.
>
> Yes I know it doesn't. And I gave a counter-example which looked like this:
>
> /* char *comment_end = "*/"; */
>
> (which also happens to match the variable more accurately, but that's
> another matter...)
>
>> rest of the source file. If you take the second, then you must
>> disallow comments of the kind I illustrated above, because your
>> lexer will trip over the unmatched ' and/or " characters.
>
> 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! */

in a comment?  Then you    don't   want comments that nest.

     Comments are not for suppressing blocks of code; comments are
for commentary.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#13191

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

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

-- 
Bartc

 

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

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

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

csiph-web