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

#13189

On 2011-11-12, 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.

That's true, but it does so by being a binary operator which
requires two operands.

The ; is not an operator, but a punctuator which terminates.

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

#13184

On 11/12/2011 9:21 AM, Stephen Sprunk wrote:
> 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?

     Do you think `*;' should be valid?

     (If so, how many operands have been omitted? ;-)

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

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

#13213

On 12-Nov-11 08:44, Eric Sosman wrote:
> On 11/12/2011 9:21 AM, Stephen Sprunk wrote:
>> 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?
> 
>     Do you think `*;' should be valid?
> 
>     (If so, how many operands have been omitted? ;-)

Amusing, but sort of misses the point since it hinges on _how_ "," is
defined rather than defending _why_ it is so defined.

Absent side effects, "x,y;" is equivalent to "y;".  The expression ""
cannot have side effects, so ",y;" should also be equivalent to "y;" and
therefore be valid.

Absent side effects, ",y;" is equivalent to ";".  The expression ""
cannot have side effects, so ",;" should also be equivalent to ";" and
therefore valid.

Absent side effects, "x,;" is equivalent to "x;".  The expression ""
cannot have side effects, so "x,;" should also be equivalent to ";" and
therefore valid.

The problem is that both operands must be evaluated by the operator
before it can discard the results, and the current language definition
does not define how to evaluate a null expression.  However, what if it did?

This is similar to not allowing objects of type void; such an object is
obviously meaningless, but there are certain corner cases where
uniformity matters more than meaning.

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]

#13405

On 11/11/2011 4:54 PM, Keith Thompson wrote:
> James Kuyper<jameskuyper@verizon.net>  writes:
[...]
>> 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
>          );

In such cases, I often use:

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

A little awkward, but "less ugly".


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

I definitely use such things in enums:

enum {
      foo,
      bar,
#if USE_BAZ
      baz,
#endif
#if USE_FOOBAR
      foobar,
#endif
      };


-- 
Kenneth Brody

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

#13408

On 11/16/11 08:22 AM, Kenneth Brody wrote:
> On 11/11/2011 4:54 PM, Keith Thompson wrote:
>> James Kuyper<jameskuyper@verizon.net>   writes:
> [...]
>>> 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
>>           );
>
> 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?

-- 
Ian Collins

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

#13410

On 11/15/2011 02:41 PM, Ian Collins wrote:
> On 11/16/11 08:22 AM, Kenneth Brody wrote:
>> On 11/11/2011 4:54 PM, 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
>>>           );
>>
>> 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.

To remind future maintainers that this function used to have an extra
feature, which might someday need to be reinstated. As a general rule,
it would be associated with commented-out code within the body of the
function that makes use of the parameter. Keeping this old code, rather
than relying solely on the revision-control system serves to prevent
people from forgetting about the feature.
I've done things like this during debugging, but not for delivered code.

> Why not just remove the unused parameter?

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

#13413

On 11/16/11 08:48 AM, James Kuyper wrote:
> On 11/15/2011 02:41 PM, Ian Collins wrote:
>> On 11/16/11 08:22 AM, Kenneth Brody wrote:
>>> On 11/11/2011 4:54 PM, 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
>>>>            );
>>>
>>> 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.
>
> To remind future maintainers that this function used to have an extra
> feature, which might someday need to be reinstated. As a general rule,
> it would be associated with commented-out code within the body of the
> function that makes use of the parameter. Keeping this old code, rather
> than relying solely on the revision-control system serves to prevent
> people from forgetting about the feature.

That path is fraught with danger.  The commented out code will become 
stale because no one would bother to maintain it (for how could it be 
tested?).  It is far better to leave the original, in context, on a 
branch and keep the main line clean.

-- 
Ian Collins

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

#13419

"Ian Collins" <ian-news@hotmail.com> wrote in message 
news:9iftjkFi5oU1@mid.individual.net...
> 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?

Because commenting something out isn't the same as deleting it for good.

Have you never written experimental code?

Besides, as soon as you delete a nondescript piece of code, usually the 
application will suddenly stop working. With the weaker commitment of a 
commenting-out, you can reinstate the code very easily.

Or sometimes you want to replace one bit of code by a variation of it, but 
you still need the original code visible to work from. If the new version is 
not quite right, you again need the original to start again. Quite often 
there will be something in a line that is causing a problem, and you 
temporarily comment-out different bits to investigate it.

Anyway there are dozens of reasons why people want to have commented-out 
code, I don't think anyone disputes that. (Except perhaps you with your 
super-duper version control systems which can remember and recover any mod 
you ever did; in which case  why should you care what anyone else uses 
comments for?)

I just happen to think that #if 0 is a ugly way of doing this (with a few 
problems of it's own), while nested comments is an elegant way.

-- 
Bartc
 

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

#13422

On 11/16/11 09:37 AM, BartC wrote:
> "Ian Collins"<ian-news@hotmail.com>  wrote in message
> news:9iftjkFi5oU1@mid.individual.net...
>> 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?
>
> Because commenting something out isn't the same as deleting it for good.
>
> Have you never written experimental code?

Often, but it doesn't find its way into production code.

> Besides, as soon as you delete a nondescript piece of code, usually the
> application will suddenly stop working. With the weaker commitment of a
> commenting-out, you can reinstate the code very easily.

Or in my case, the tests will fail and I'll revert the change.

> Or sometimes you want to replace one bit of code by a variation of it, but
> you still need the original code visible to work from. If the new version is
> not quite right, you again need the original to start again. Quite often
> there will be something in a line that is causing a problem, and you
> temporarily comment-out different bits to investigate it.

If this happens during an editing session, use the editor's undo/redo 
facility.

If I want to make a change while keeping the original, I either open the 
parent version in another editor window, or more often, open a visual 
diff which highlights the changes clearly.

> Anyway there are dozens of reasons why people want to have commented-out
> code, I don't think anyone disputes that. (Except perhaps you with your
> super-duper version control systems which can remember and recover any mod
> you ever did; in which case  why should you care what anyone else uses
> comments for?)

Using version control isn't rocket science.  Subversion, git and 
mercurial give you all the tools you need.  They also integrate well 
into the popular open source IDEs.

See my reply to James Kuyper, keeping stale, commented out code around 
is as bad, if not worse, than having out of date design documents.

-- 
Ian Collins

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

#13428

"BartC" <bc@freeuk.com> writes:
[...]
> I just happen to think that #if 0 is a ugly way of doing this (with a few 
> problems of it's own), while nested comments is an elegant way.

It doesn't matter how elegant nested comments might or might not be.
They simply don't exist in C.  I have yet to see you acknowledge that.

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

#13436

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnk47110ho.fsf@nuthaus.mib.org...
> "BartC" <bc@freeuk.com> writes:
> [...]
>> I just happen to think that #if 0 is a ugly way of doing this (with a few
>> problems of it's own), while nested comments is an elegant way.

OK, 'would be an' instead of 'is an'.

> It doesn't matter how elegant nested comments might or might not be.
> They simply don't exist in C.  I have yet to see you acknowledge that.

Clearly they don't, for arbitrary levels of /*...*/ comments, otherwise this 
thread wouldn't exist.

Although nested comments of sorts can be achieved to a limited extent with
some combination of /*...*/, // and #if 0.

-- 
Bartc 

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

#13441

On 2011-11-15, BartC <bc@freeuk.com> wrote:
> "Ian Collins" <ian-news@hotmail.com> wrote in message 
> news:9iftjkFi5oU1@mid.individual.net...
>> 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".

[ ... ]

>> Why not just remove the unused parameter?
>
> I just happen to think that #if 0 is a ugly way of doing this (with a few 
> problems of it's own), while nested comments is an elegant way.

I showed several times how a simple macro can do it this way within
one line:

#define IGN(...)  /* C99 variadic */

  some_function(10, 20, IGN(30, ) );

Nests and everything:

 IGN( IGN ( ... ) IGN ( IGN ( ... ) ) )

A limitation is that the the stuff that is being commented out has to have
balanced parentheses. I could live with that.

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

#13447

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

>> I just happen to think that #if 0 is a ugly way of doing this (with a few
>> problems of it's own), while nested comments is an elegant way.
>
> I showed several times how a simple macro can do it this way within
> one line:
>
> #define IGN(...)  /* C99 variadic */
>
>  some_function(10, 20, IGN(30, ) );
>
> Nests and everything:
>
> IGN( IGN ( ... ) IGN ( IGN ( ... ) ) )

I didn't believe it, but it seems to work...

> A limitation is that the the stuff that is being commented out has to have
> balanced parentheses. I could live with that.

I called mine COM() (why IGN?), and it means comments can be written like 
this:

 COM(...)

instead of:

/*...*/

But, both have similar problems in that either ( and ), or /* and */, must 
be balanced, so from that point of view, what would be the difference?

Of course, nested COM() (or whatever it might be called) exists now, and 
nested /**/ doesn't. But the argument against nested /**/ *was* that stray 
/* or */ sequences would trip it up, in the same way that extra ( or ) might 
cause a problem in the macro.

-- 
Bartc 

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

#13454

On 2011-11-15, BartC <bc@freeuk.com> wrote:
> "Kaz Kylheku" <kaz@kylheku.com> wrote in message 
> news:20111115150328.947@kylheku.com...
>> On 2011-11-15, BartC <bc@freeuk.com> wrote:
>
>>> I just happen to think that #if 0 is a ugly way of doing this (with a few
>>> problems of it's own), while nested comments is an elegant way.
>>
>> I showed several times how a simple macro can do it this way within
>> one line:
>>
>> #define IGN(...)  /* C99 variadic */
>>
>>  some_function(10, 20, IGN(30, ) );
>>
>> Nests and everything:
>>
>> IGN( IGN ( ... ) IGN ( IGN ( ... ) ) )
>
> I didn't believe it, but it seems to work...

Why didn't you believe it? I often test stuff before posting! :)

>> balanced parentheses. I could live with that.
>
> I called mine COM() (why IGN?), and it means comments can be written like 
> this:

Because, sigh, it's not commenting! It's for ignoring program tokens.

IGN comes from the Common Lisp habit:  #+IGN expr  causes expr to be
ignored, assuming the symbol :IGN is not in the platform *features* list.
I've never seen Lisp's #+ or #- used for commenting; that is ridiculous.

(Lisp people: don't shoot me, I know this kludge is frowned upon by some,
and I don't use it myself, but rather #+(and) expr.)

> But, both have similar problems in that either ( and ), or /* and */, must 
> be balanced, so from that point of view, what would be the difference?
> Of course, nested COM() (or whatever it might be called) exists now, and 
> nested /**/ doesn't. But the argument against nested /**/ *was* that stray 
> /* or */ sequences would trip it up, in the same way that extra ( or ) might 
> cause a problem in the macro.

The differences is that the stuff inside IGN(...) is preprocessor tokens, not
an arbitrary comment. It syntactically has to be a valid macro call! So it is
not messed up by the following:

     IGN( char lparen = '('; )

On the other and it is messed up by this:

     if (!x)
       foo(); IGN(Don't foo if x is true!)

Do you still want to call it COM?

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

#13434

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?

      some_function( 10 /* param1 */
                    ,20 /* param2 */
#ifdef EXTRA_PARAMS
                    ,30 /* param3 */
#endif
                   );

Oh, and besides that, writing it like above makes it easier to avoid merge
conflicts in sources where parameters are often tacked on at the end.


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]

#13437

On 11/16/11 11:40 AM, Willem wrote:
> 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?
>
>        some_function( 10 /* param1 */
>                      ,20 /* param2 */
> #ifdef EXTRA_PARAMS
>                      ,30 /* param3 */
> #endif
>                     );

In that case, why not

#ifdef EXTRA_PARAMS
   some_function( 10, 20, 30 );
#else
   some_function( 10, 20 );
#endif

rather than adopt a naff style for some calls?

> Oh, and besides that, writing it like above makes it easier to avoid merge
> conflicts in sources where parameters are often tacked on at the end.

So does my alternative.

-- 
Ian Collins

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

#13443

On 2011-11-15, Willem <willem@toad.stack.nl> wrote:
> 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?
>
>       some_function( 10 /* param1 */
>                     ,20 /* param2 */
> #ifdef EXTRA_PARAMS
>                     ,30 /* param3 */
> #endif
>                    );
>
> Oh, and besides that, writing it like above makes it easier to avoid merge
> conflicts in sources where parameters are often tacked on at the end.

In a situation where multiple developers find themselves regularly pounding on
new parameters onto the same set of functions,  you want the coding convention
to be such that it maximizes the likelihood of a merge conflict, so they stop
and carefully review their integration process.  There may still be a semantic
conflict even if you avoid the textual one. A new parameter being added to a
function that you've locally modified (including its argument list) is probably
a big deal, which could invalidate whatever you're doing inside that function.

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

#13491

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


-- 
Kenneth Brody

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

#13497

On 11/17/11 06:57 AM, Kenneth Brody wrote:
> 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
>                );

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

-- 
Ian Collins

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

#13498

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?

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

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

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

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

csiph-web