Why don't C comments nest?

[Kaz Kylheku]

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.

 

[BartC]

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.

 

[Kaz Kylheku]

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

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

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?

 

[Ian Collins]

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

 

[John Gordon]

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?

 

[Ian Collins]

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.

 

[Keith Thompson]

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.

 

[Ben Pfaff]

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

 

[Ian Collins]

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

 

[Kaz Kylheku]

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.

 

[Ian Collins]

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

 

[Noob]

However, some will generate a warning ;-)

 

[Phil Carmody]

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

 

[Phil Carmody]

However, some will generate a warning ;-)

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

Phil

 

[James Kuyper]

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

 

[Phil Carmody]

On 11/18/2011 08:49 AM, Phil Carmody wrote:
...

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