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

#13110 — Why don't C comments nest?

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

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?

Thanks! 

[toc] | [next] | [standalone]

#13112

On 11/11/2011 02:21 PM, Aron Packer 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).
> 
> 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?

The Rationale (Revision 5.1.0 April-2003) says:
> The C89 Committee considered proposals to allow comments to nest. The main argument for
> nesting comments is that it would allow programmers to “comment out” code. The C89
> Committee rejected this proposal on the grounds that comments should be used for adding
> documentation to a program, and that preferable mechanisms already exist for source code
> exclusion. For example,
>
>       #if 0
>             /* code to be excluded */
>       #endif
>
> Preprocessing directives such as this prevent the enclosed code from being scanned by later
> translation phases. Bracketed material can include comments and other nested regions of
> bracketed code.
>
> Another way of accomplishing these goals is with an if statement:
>      if (0) {
>            /* code to be excluded */
>      }
>
> Many modern compilers will generate no code for this if statement.

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

#13548

James Kuyper wrote:

>> Another way of accomplishing these goals is with an if statement:
>>      if (0) {
>>            /* code to be excluded */
>>      }
>>
>> Many modern compilers will generate no code for this if statement.

However, some will generate a warning ;-)

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

#13592

Noob <root@127.0.0.1> writes:
> James Kuyper wrote:
> 
> >> Another way of accomplishing these goals is with an if statement:
> >>      if (0) {
> >>            /* code to be excluded */
> >>      }
> >>
> >> Many modern compilers will generate no code for this if statement.
> 
> However, some will generate a warning ;-)

I support both behaviours. Such code is smell, and getting rid of smells
should be encouraged.

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

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

#13113

On Nov 11, 11:21 am, Aron Packer <a...@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).
>
> 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?
>
> Thanks!

Well, it does make parsing a little easier.  If you try to write a C-
comment remover, which I believe is an exercise in K&R, you'd probably
see why.

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

#13116

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.

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.

If you don't have this kind of robustness, there is no point in allowing nested
comments.

Either solve the embedding problem 100% or don't bother.

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
skipped by the preprocessor is still decomposed into tokens.
This is why we don't use it for writing comments.

The upshot is that /* */ is for writing comments and #if ... #endif
is for "compiling out" code you don't want.

Consideration 2:

Nesting C comments are not recognizeable by a finite automaton (regular
language). They require a push-down automaton or counter: something
to keep track of the nesting levels so every open /* is balanced
by a closing */.

This is a minor thing but it does mean that in a lexical analyzer generator
based on a tool like lex, you have to write dedicated code for C comments.
(This is sometimes done in practice anyway even for non-nesting comments,
because the regex for C comments is convoluted and ugly if the regex language
does not support advanced operators like a non-greedy Kleene star, or
complement.)

It is nevertheless a useful fact that C can be tokenized purely with regexes,
ugly or not, including the recognition of comments.

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

#13118

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

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

I've programmed nested comments in lexers before, and most of the time they
work fine. (It seems to be mostly commenting-out blocks of lexer code, which
is full of literals and comments to do with comment-processing, that cause
problems.)

> If you don't have this kind of robustness, there is no point in allowing
> nested
> comments.
> Either solve the embedding problem 100% or don't bother.

The above example (and a there are a few more) show that even normal
comments aren't 100% robust, so what's the difference? Nobody's going to be 
forcing anyone to make use of them.

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


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

-- 
Bartc
 

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

#13120

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

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

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.

    some_func(10 /* param1 */, 20 /* param2 */, 30 /* param3 */);

The comments are there to show the names of the actual parameters,
without which "some_func(10, 20, 30);" isn't nearly as clear.

Then some_func is changed so it only takes 2 parameters, but you want to
keep the information about the 3rd one in the source for some reason.

First, consider whether that's really worth doing.  You can just delete
the third argument altogether:

    some_func(10 /* param1 */, 20 /* param2 */);

and if you need to see the 3-argument version of the call, you can just
look in your source control system.  (You *are* using one, right?)

But ok, let's say there's a good reason to keep the original version as
a comment.  Here's how I might do it:

#if 0
    some_func(10 /* param1 */, 20 /* param2 */, 30 /* param3 */);
#else
    some_func(10 /* param1 */, 20 /* param2 */);
#endif

Any definition of how comments work (nesting vs. non-nesting,
single-line vs. end-of-line vs. partial-line vs. multi-line, etc.) is
going to be inconvenient for some purposes.  None of these
inconveniences are insurmountable.

And of course changing the rules now would break existing code.  I've
seen code that specifically depends on the fact that /**/ comments
*don't* nest.

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

#13121

On 11/11/2011 04:16 PM, Keith Thompson wrote:
> "BartC" <bc@freeuk.com> writes:
...
>> 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.
> 
>     some_func(10 /* param1 */, 20 /* param2 */, 30 /* param3 */);
> 
> The comments are there to show the names of the actual parameters,
> without which "some_func(10, 20, 30);" isn't nearly as clear.
> 
> Then some_func is changed so it only takes 2 parameters, but you want to
> keep the information about the 3rd one in the source for some reason.
> 
> First, consider whether that's really worth doing.  You can just delete
> the third argument altogether:
> 
>     some_func(10 /* param1 */, 20 /* param2 */);
> 
> and if you need to see the 3-argument version of the call, you can just
> look in your source control system.  (You *are* using one, right?)
> 
> But ok, let's say there's a good reason to keep the original version as
> a comment.  Here's how I might do it:
> 
> #if 0
>     some_func(10 /* param1 */, 20 /* param2 */, 30 /* param3 */);
> #else
>     some_func(10 /* param1 */, 20 /* param2 */);
> #endif

My preference is

    some_func(10 /* param1 */, 20 /* param2 */
#if 0
                                              , 30 /* param3 */
#endif
                                                               );

But I can understand why some might consider that ugly.

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

#13126

James Kuyper <jameskuyper@verizon.net> writes:
> On 11/11/2011 04:16 PM, Keith Thompson wrote:
[...]
>> But ok, let's say there's a good reason to keep the original version as
>> a comment.  Here's how I might do it:
>> 
>> #if 0
>>     some_func(10 /* param1 */, 20 /* param2 */, 30 /* param3 */);
>> #else
>>     some_func(10 /* param1 */, 20 /* param2 */);
>> #endif
>
> My preference is
>
>     some_func(10 /* param1 */, 20 /* param2 */
> #if 0
>                                               , 30 /* param3 */
> #endif
>                                                                );
>
> But I can understand why some might consider that ugly.

If a comma were permitted after the last parameter declaration, you
could just write:

    some_function(10 /* param1 */,
                  20 /* param2 */,
#if 0
                  30 /* param3 */,
#endif
        );

C99 changed the syntax to permit a trailing comma in an enum
declaration.  It would have made sense to permit a trailling
comma for *any* comma-separated list.  (Probably not for the comma
operator, though.)

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

#13177

Keith Thompson wrote:
) If a comma were permitted after the last parameter declaration, you
) could just write:
)
)     some_function(10 /* param1 */,
)                   20 /* param2 */,
) #if 0
)                   30 /* param3 */,
) #endif
)         );

Which is why I have changed my preference to writing this:

    some_function(10 /* param1 */
                 ,20 /* param2 */
#if 0
                 ,30 /* param3 */
#endif
        );

And not only in C, but in almost any language.

The point is that this plays a lot nicer with revision control systems,
because adding or removing an argument is a 1-line change, whereas in the
other case it can potentially change the previous line as well.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

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

#13200

Willem <willem@toad.stack.nl> writes:
> Keith Thompson wrote:
> ) If a comma were permitted after the last parameter declaration, you
> ) could just write:
> )
> )     some_function(10 /* param1 */,
> )                   20 /* param2 */,
> ) #if 0
> )                   30 /* param3 */,
> ) #endif
> )         );
>
> Which is why I have changed my preference to writing this:
>
>     some_function(10 /* param1 */
>                  ,20 /* param2 */
> #if 0
>                  ,30 /* param3 */
> #endif
>         );
>
> And not only in C, but in almost any language.
>
> The point is that this plays a lot nicer with revision control systems,
> because adding or removing an argument is a 1-line change, whereas in the
> other case it can potentially change the previous line as well.

And if you want to comment out the *first* argument?

I see your point, but personally I find that layout rather hard on
my eyes.  The need to comment out a single parameter is rare enough
that I don't think it's worth 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]

#13212

Keith Thompson wrote:
) Willem <willem@toad.stack.nl> writes:
)> Which is why I have changed my preference to writing this:
)>
)>     some_function(10 /* param1 */
)>                  ,20 /* param2 */
)> #if 0
)>                  ,30 /* param3 */
)> #endif
)>         );
)>
)> And not only in C, but in almost any language.
)>
)> The point is that this plays a lot nicer with revision control systems,
)> because adding or removing an argument is a 1-line change, whereas in the
)> other case it can potentially change the previous line as well.
)
) And if you want to comment out the *first* argument?
)
) I see your point, but personally I find that layout rather hard on
) my eyes.  The need to comment out a single parameter is rare enough
) that I don't think it's worth it.

And the need to play nice with revision control systems ?
I do it a lot more for the benefit of version control than anything else
(though commenting out is a very rudimentary form of version control.)

If the language did allow a trailing comma, it wouldn't be an issue,
and even a change on the first argument would not be a problem:

  some_function(
      10, /* param1 */
      20, /* param2 */
      30, /* param3 */
    );

Not allowing trailing commas means you wither get in trouble for the first
argument, or the last argument.  Oh, and it makes automatic code generation
a tiny bit harder as well (generating JSON has the same problem).

So I would be all in favour of this feature.
Is there any possible (existing) code that this would break ?
AFAIK, it will turn something that was a syntax error into good code.
(It may even be that existing implementations are allowed to let you off
 with a warning and generate code as if the trailing comma weren't there.)


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

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

#13220

Willem <willem@toad.stack.nl> writes:
> Keith Thompson wrote:
> ) Willem <willem@toad.stack.nl> writes:
> )> Which is why I have changed my preference to writing this:
> )>
> )>     some_function(10 /* param1 */
> )>                  ,20 /* param2 */
> )> #if 0
> )>                  ,30 /* param3 */
> )> #endif
> )>         );
> )>
> )> And not only in C, but in almost any language.
> )>
> )> The point is that this plays a lot nicer with revision control systems,
> )> because adding or removing an argument is a 1-line change, whereas in the
> )> other case it can potentially change the previous line as well.
> )
> ) And if you want to comment out the *first* argument?
> )
> ) I see your point, but personally I find that layout rather hard on
> ) my eyes.  The need to comment out a single parameter is rare enough
> ) that I don't think it's worth it.
>
> And the need to play nice with revision control systems ?
> I do it a lot more for the benefit of version control than anything else
> (though commenting out is a very rudimentary form of version control.)

Revision control systems can fend for themselves.  If they end up
storing an extra line or two of diffs, that's not much of a problem.
Diff tools can be configured to show a few lines of context around each
change; some do so by default.

> If the language did allow a trailing comma, it wouldn't be an issue,
> and even a change on the first argument would not be a problem:
>
>   some_function(
>       10, /* param1 */
>       20, /* param2 */
>       30, /* param3 */
>     );
>
> Not allowing trailing commas means you wither get in trouble for the first
> argument, or the last argument.  Oh, and it makes automatic code generation
> a tiny bit harder as well (generating JSON has the same problem).
>
> So I would be all in favour of this feature.
> Is there any possible (existing) code that this would break ?
> AFAIK, it will turn something that was a syntax error into good code.
> (It may even be that existing implementations are allowed to let you off
>  with a warning and generate code as if the trailing comma weren't there.)

A syntax error, like a constraint violation, merely requires the
compiler to issue a diagnostic.  What it does after that is undefined.

More realistically, perhaps, a compiler could permit trailing commas in
a non-conforming mode (most compilers are non-conforming by default
anyway).

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

#13243

Keith Thompson wrote:
) Willem <willem@toad.stack.nl> writes:
)> And the need to play nice with revision control systems ?
)> I do it a lot more for the benefit of version control than anything else
)> (though commenting out is a very rudimentary form of version control.)
)
) Revision control systems can fend for themselves.  If they end up
) storing an extra line or two of diffs, that's not much of a problem.
) Diff tools can be configured to show a few lines of context around each
) change; some do so by default.

It's the merging where the problems start.  I know, I've seen it happen.
Enough times for me to change my preference to the comma at the start of
theline, which would have avoided those merge conflicts.

)> So I would be all in favour of this feature.
)> Is there any possible (existing) code that this would break ?
)> AFAIK, it will turn something that was a syntax error into good code.
)> (It may even be that existing implementations are allowed to let you off
)>  with a warning and generate code as if the trailing comma weren't there.)
)
) A syntax error, like a constraint violation, merely requires the
) compiler to issue a diagnostic.  What it does after that is undefined.

So yes, they are allowed to let you off with a warning?
AFAIK, an implementation can define what it does in the case of certain
undefined behaviour.  So, here's to compiler writers: make it a warning!

) More realistically, perhaps, a compiler could permit trailing commas in
) a non-conforming mode (most compilers are non-conforming by default
) anyway).

If enough compilers permit it, it would go into the next standard.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

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

#13244

On 11/13/2011 05:30 AM, Willem wrote:
> Keith Thompson wrote:
...
> ) A syntax error, like a constraint violation, merely requires the
> ) compiler to issue a diagnostic.  What it does after that is undefined.
> 
> So yes, they are allowed to let you off with a warning?
> AFAIK, an implementation can define what it does in the case of certain
> undefined behaviour.

You can drop the word "certain" there, It is always the case that if the
behavior is undefined, the C standard imposes no restrictions, leaving
an implementation free to provide its own definition.
-- 
James Kuyper

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

#13252

James Kuyper wrote:
) On 11/13/2011 05:30 AM, Willem wrote:
)> Keith Thompson wrote:
) ...
)> ) A syntax error, like a constraint violation, merely requires the
)> ) compiler to issue a diagnostic.  What it does after that is undefined.
)> 
)> So yes, they are allowed to let you off with a warning?
)> AFAIK, an implementation can define what it does in the case of certain
)> undefined behaviour.
)
) You can drop the word "certain" there, It is always the case that if the
) behavior is undefined, the C standard imposes no restrictions, leaving
) an implementation free to provide its own definition.

Yes, but the implementation can choose that it only does that for some
behaviours, and not for others.  I see how the wording is confusing.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

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

#13181

On 11-Nov-11 15:54, Keith Thompson wrote:
> C99 changed the syntax to permit a trailing comma in an enum
> declaration.  It would have made sense to permit a trailling
> comma for *any* comma-separated list.  (Probably not for the comma
> operator, though.)

Why not?  If ";" is a valid statement, then why shouldn't ",;" be valid?

S


-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#13182

In article <j9lvd7$mn0$2@dont-email.me>,
Stephen Sprunk  <stephen@sprunk.org> wrote:
> Why not?  If ";" is a valid statement, then why shouldn't ",;" be valid?

Because the comma operator separates expressions, not statements.


Lauri

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

#13185

In article <j9lvrn$5kp$1@oravannahka.helsinki.fi>, Lauri Alanko <la@iki.fi> 
wrote:

> In article <j9lvd7$mn0$2@dont-email.me>,
> Stephen Sprunk  <stephen@sprunk.org> wrote:
> > Why not?  If ";" is a valid statement, then why shouldn't ",;" be valid?
> 
> Because the comma operator separates expressions, not statements.

Because comma separates and semicolon terminates.

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

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

csiph-web