John Forkosh <forkosh@panix.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> John Forkosh <forkosh@panix.com> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>
>>>> John Forkosh <forkosh@panix.com> writes:
>>>>
>>>>> Consider a macro of the form
>>>>> /* --- set north=parent,south=child,east=next,
>>>>> west=previous link of node --- */
>>>>> #define setlink(ptr,nsew,link) if ( checknode(ptr) ) \
>>>>> ((node *)(ptr))->nsew = (node *)(link)
>>>>> Not important exactly what it does, just the if(xxx)yyy
>>>>> construction.
>>>>>
>>>>> Now, suppose I want to use it like
>>>>> if ( xxx ) setlink(a,b,c); else yyy;
>>>>> Then the compiler warns that the binding of that else yyy; is
>>>>> ambiguous.
>>>>>
>>>>> I clearly mean
>>>>> if ( xxx ) {setlink(a,b,c);} else yyy;
>>>>> but it's cumbersome and inelegant to write it that way again and again.
>>>>>
>>>>> Likewise, if I try to define the macro with the {}'s (and the
>>>>> trailing ;)
>>>>> #define setlink(ptr,nsew,link) { if ( checknode(ptr) ) \
>>>>> ((node *)(ptr))->nsew = (node *)(link); }
>>>>> Then writing setlink(a,b,c); in the code has that extraneous ;
>>>>> which can then again cause the same kind of confusion. But
>>>>> omitting the ; just looks wrong and ugly.
>>>>>
>>>>> So what's a way to define the macro that simultaneously removes
>>>>> any potential semantic confusion without introducing the
>>>>> necessity of any unpretty syntax?
>>>>
>>>> There is a conventional idiom for this:
>>>>
>>>> #define setlink(ptr,nsew,link) \
>>>> do { \
>>>> if ( checknode(ptr) ) \
>>>> ((node *)(ptr))->nsew = (node *)(link); \
>>>> } while (0)
>>>>
>>>> (The {}s are optional in this case.)
>>>
>>> Thanks. Okay, I'll try adopting that conventional style.
>>> Looks a bit elaborate to me, but if that's the convention
>>> then I guess I can get comfortable with it.
>>
>> Most C programmers won't bat an eyelid at it, but I agree it's
>> clumsy.
>>
>> When the contingent action is actually just an expression, you can
>> avoid the if (...) altogether like this:
>>
>> #define setlink(ptr,nsew,link) \
>> ( checknode(ptr) && (((node *)(ptr))->nsew = (node *)(link)) )
>>
>> so that there are no 'else' issues at all.
>
> Thanks, again, for the alternative solution. I actually like it a
> little better since it avoids the klutzy do-while construction that
> has no useful purpose and might only confuse the casual reader,
> i.e., "What the heck is he doing that for?" But then again, I never
> much liked relying that (a&&b) always evaluates a first, immediately
> becoming 0 without evaluating b at all if a is itself 0. You never
> know exactly what the next C standard might mess around with.
> But your suggestion itself suggested the more explicit version
> #define setlink(ptr,nsew,link) \
> ( checknode(ptr)? (((node *)(ptr))->nsew = (node *)(link)) : 0 )
> which I think accomplishes the same thing with explicitly visible
> logic.

In cases like this one I usually find an expressional form works
better than a statement form, and ?: better than && (unless of
course the second part of the && is also a predicate and the
overall value is important, in which case it can depend on the
subexpressions involved).

John Forkosh <forkosh@panix.com> writes:

> David Brown <david.brown@hesbynett.no> wrote:

[...]

>> And I recommend you get in the habit of writing :
>> if (xxx) {
>> setlink(a, b, c);
>> } else {
>> yyy;
>> }
>> People vary in their opinions and styles, of course, ...
>
> Yuk! My, but that's ugly. :) For just one statement in the
> if-clause and/or else-clause, I typically wouldn't use {}'s at
> all. And for just a few statements, I typically write it like
> if (xxx) {
> setlink(a, b, c);
> getlink(d, e, f); }
> else {
> yyy;
> zzz; }

Despite your visceral reaction, the layout you suggest here is
objectively inferior along at least one important axis. Studies
of various rules for bracketing layout have found that lining up
closing brackets (which are braces in this case) with the start
of their corresponding opening lines (ie, like the quoted example
recommendation) gives the lowest error rates of all the layout
styles looked at (including the "lisp style" layout you suggest).
The layout you prefer has higher error rates than the "ugly"
layout you dislike. I think any developer who is serious about
writing good code would want to follow a layout style that has
lower error rates, whatever their personal reactions might be.