cond. op. on ='s LHS

[Richard Harter]

In article <1196 at sheol.UUCP>, throopw at sheol.UUCP (Wayne Throop) writes:
> - gwyn at smoke.brl.mil (Doug Gwyn)
> -- rh at smds.UUCP (Richard Harter)
> 
> -- [.. some context restored ..]
> --       *(a==b?&c:&d) = <some complicated messy expression>
> -- However the ugly one liner is better code in the sense of not having
> -- replications of a single term or in using temporaries.  [...] In
> -- principle the idea is a good one but the C conditional expression is
> -- just too darned ugly. 
> - There are good ways of exploiting the ?: operator and bad ways.
> - The example being discussed is clearly among the latter.

As Doug points out in another message the original had 1. instead of
a complex expression.  

> I'm not sure I understand.  Could either Doug or Richard expand a little
> on just why the expression is "ugly" or a "bad way" to exploit the
> conditional operator?  It doesn't seem any worse than, say

>          foo[a==b?c:d] = something;

> or even just

>          foo[(a+b)*(c+d)] = something;

> or the like.  All are examples of a complicated decision going into
> exactly which object is going to be assigned to.  Granted, the
> conditional is more extreme than the subscripting examples, but not to
> any large degree IMHO.  So why is the explicit conditional any worse
> than the others?

Let's run down the line on this.  First of all the trick of using
*(cond?&var1:&var2) is not technically legal since the result of the
?: is not an lvalue.  [Harbison & Steele].  I rather suspect you could
sneak it past most compilers though.   However by doing so you are are
violating the specs and the intent of the language [for what that's
worth.]

Secondly the syntax of the condition is, in its own right, ugly.  This
is a personal opinion, but it is seconded by some noted practioners of
the art.  Why is it ugly?  It is ugly because it has special rules and
syntax that do not fit the rest of the language.  C is (despite the
complaints) actually a fairly elegant and well designed language.  The
syntax is quite regular.  The conditional uses special symbols in a way
that is not very consistent with the rest of the language.  Call this
an esthetic objection if you like.

Thirdly, the use of the conditional in an lvalue obscures the destination
of an assignment.  This is equally true whether you write

	*(a==b?&x:&y) = expression;  /* ugh */
or	f[a==b?i:j]   = expression;  /* not quite as bad */

If you are reading the code it is less than obvious what is being set.

Fourthly, the ?: is hard to read (see second complaint above).  It is
particularly hard to read when it is used as a sub expression.  Let me
give an example, with apologies to Rich Salz:

	/* This next line requires a good C compiler. */
	if (*p == '-' ? *text <= *++p && *text >= last : *text == *p)
	    matched = TRUE;

Fifthly, the original example is an instance of making code less efficient
in the process of reducing the number of statements since you have to
reference and dereference.  In the old days beginning programmers had
to learn the hard way that clever tricks to reduce the number of lines
of code often lead to code that took longer to execute.

Having said all these nasty things, are there any reasons why one would
use the conditional?  One can do without it -- I wrote C for five years
before I used my first conditional.  One reason, which several people
have mentioned, is that it facilitates macro writing.  Another is that
it does, in fact, solve a real problem.  There really is a need for
conditional expressions.
-- 
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb.  This sentence short.  This signature done.