Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Why don't C comments nest?

Reply
Thread Tools

Why don't C comments nest?

 
 
Kaz Kylheku
Guest
Posts: n/a
 
      11-15-2011
On 2011-11-15, Willem <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
BartC
Guest
Posts: n/a
 
      11-15-2011
"Kaz Kylheku" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 2011-11-15, BartC <(E-Mail Removed)> 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

 
Reply With Quote
 
 
 
 
Kaz Kylheku
Guest
Posts: n/a
 
      11-16-2011
On 2011-11-15, BartC <(E-Mail Removed)> wrote:
> "Kaz Kylheku" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> On 2011-11-15, BartC <(E-Mail Removed)> 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?
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      11-16-2011
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
 
Reply With Quote
 
John Gordon
Guest
Posts: n/a
 
      11-16-2011
In <(E-Mail Removed)> Ian Collins <(E-Mail Removed)> 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
http://www.velocityreviews.com/forums/(E-Mail Removed) B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      11-16-2011
On 11/17/11 07:57 AM, John Gordon wrote:
> In<(E-Mail Removed)> Ian Collins<(E-Mail Removed)> 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
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-16-2011
Ian Collins <(E-Mail Removed)> writes:
> On 11/17/11 07:57 AM, John Gordon wrote:
>> In<(E-Mail Removed)> Ian Collins<(E-Mail Removed)> 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) (E-Mail Removed) <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      11-16-2011
Ian Collins <(E-Mail Removed)> 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,0xa6 7f6aaa,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 1utchar(a[i&15]);break;}}}
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      11-16-2011
On 11/17/11 08:50 AM, Keith Thompson wrote:
> Ian Collins<(E-Mail Removed)> writes:
>> On 11/17/11 07:57 AM, John Gordon wrote:
>>> In<(E-Mail Removed)> Ian Collins<(E-Mail Removed)> 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
 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      11-16-2011
On 2011-11-16, Keith Thompson <(E-Mail Removed)> wrote:
> Ian Collins <(E-Mail Removed)> writes:
>> On 11/17/11 07:57 AM, John Gordon wrote:
>>> In<(E-Mail Removed)> Ian Collins<(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
A program to replace all JS comments with JSP comments in jsp files tungchau81@yahoo.com Javascript 4 06-03-2006 02:00 PM
A program to replace all JS comments with JSP comments in jsp files tungchau81@yahoo.com Java 0 06-02-2006 06:35 AM
Comments format: comments extending over multi-line Monk C Programming 10 04-20-2005 05:09 PM



Advertisments