«

On 2011-11-15, 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
> );
>
> 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.

"Kaz Kylheku" <> wrote in message
news:...
> On 2011-11-15, BartC <> 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

On 2011-11-15, BartC <> wrote:
> "Kaz Kylheku" <> wrote in message
> news:...
>> On 2011-11-15, BartC <> 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?

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

In <> Ian Collins <ian-> 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
B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

On 11/17/11 07:57 AM, John Gordon wrote:
> In<> Ian Collins<ian-> 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

Ian Collins <ian-> writes:
> On 11/17/11 07:57 AM, John Gordon wrote:
>> In<> Ian Collins<ian-> 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- <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Ian Collins <ian-> 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;}}}

On 11/17/11 08:50 AM, Keith Thompson wrote:
> Ian Collins<ian-> writes:
>> On 11/17/11 07:57 AM, John Gordon wrote:
>>> In<> Ian Collins<ian-> 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

On 2011-11-16, Keith Thompson <kst-> wrote:
> Ian Collins <ian-> writes:
>> On 11/17/11 07:57 AM, John Gordon wrote:
>>> In<> Ian Collins<ian-> 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.