e1?(void_e2):(void_e3)

Wayne Throop throopw at dg_rtp.UUCP
Tue Aug 12 03:39:01 AEST 1986


> franka at mmintl.UUCP (Frank Adams)

> It seems clear that according to the ANSI draft, e1?e2:e3 is legal when e2
> and e3 are both void.  The next question is, should it be?
> It seems to me that there are two different paradigms for how to interpret
> the ?: operator here.  One is as an ordinary operator, which returns one of
> the values of e2 or e3, depending on the value of e1.  Under this
> interpretation, it does not seem to me appropriate to permit e2 and e3 void,
> since in that case they have no values.

Well, not quite.  The standard takes the position that, while a void
expression has no value, it has something that is close enough for
government work.  A way to think of is that a void expression indicates
a "value" which requires no storage and has no legal operations (other
than selection operations).  Then specifically, the ?: operation chooses
which of these odd non-value values to "evaluate".

> The other paradigm is that e1?e2:e3 is precisely one of e2 or e3, depending
> on the value of e1.

Yes.  The standard doesn't go this way.  But I think it is reasonable
for the standard to go the way it does, making void expressions legal
wherever any other expressions are, except that their result is illegal
as input for any but selection operations, such as (?:) and (,).  Any
other operation implies an interpretation and transformation of a value,
and (void) cannot be interpreted or transformed, but these operations
only imply evaluation and selection.

So I agree that there are two reasonable interpretations of (?:), and
the standard has chosen the first.  But it has also chosen an
interpretation of "what it means to be (void)" which makes void
expressions to the right of a "?" reasonable.

--
If a listener nods his head when you're explaining your program,
wake him up.
                                --- Alan J. Perlis
-- 
Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw



More information about the Comp.lang.c mailing list