cond. op. on ='s LHS

[Wayne Throop]

>  gwyn at smoke.brl.mil (Doug Gwyn)

[.. discussing *(a==b?&c:&d) = 1 ..]
> It is an abuse of the potential utility of the ?: operator to use it,
> especially with the addition of levels of indirection, where a simple
>            if ( a == b ) c = 1; else d = 1;
> would be much clearer [...] clarity is very important.

I agree strongly about the general principle of clarity.  But I suspect
I may differ in the question of what is clear.  To start with
agreement, I agree about the extra levels of indirection being
unclear.  For example,

       *(color==BLUE? &blue_items : &nonblue_items) += 1;

is more messy (and less to be prefered) than

       if( color==BLUE )
           blue_items += 1;
       else
           nonblue_items += 1;

Worse still, the former requires mumble_items to be addressable, when
they conceptually only need to be lvalues.

But on the other hand, I'd say that the GCC extension

        (color==BLUE ? blue_items : nonblue_items) += 1;

is clearer than either, and something like

        *(color==BLUE ? blue_items_ref : nonblue_items_ref) += 1;

seems perfectly clear to me, and (as a matter of taste) preferable to
the use of an "if" statement (say, inside a routine which counts item
colors as a side effect and is passed references to counts to fill in
(uh... not that I'd tend to design a routine that way, but supposing
someone did...)).

Certainly (hmmm... better say "IMHO"), it isn't much less clear than

          item_count[color] += 1;

Wayne Throop       ...!mcnc!aurgate!throop