Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!helios!archone!byron
From: byron@archone.tamu.edu (Byron Rakitzis)
Newsgroups: comp.lang.c
Subject: Re: When do you use "if ( a = b )"? (was Re: Funny mistake)
Message-ID: <13980@helios.TAMU.EDU>
Date: 1 Apr 91 05:21:05 GMT
References: <11109@dog.ee.lbl.gov> <15053@ganymede.inmos.co.uk> <10655@uwm.edu>
Sender: usenet@helios.TAMU.EDU
Organization: College of Architecture, Texas A&M University.
Lines: 57

In article <10655@uwm.edu> markh@csd4.csd.uwm.edu (Mark William Hopkins) writes:
>
>if ((A = f1()) != 2 || (A = f2()) != 3 || (A = f3()) != 4)
	[etc.]
>I believe that your proposed definition of clarity would be turned on its head
>with this example.

I don't know whose definition of clarity you were referring to, but I don't
think any of the "anti-assignment-in-if-statement" people can object with
the above line. Note that the above line does *not* read:

	if (!(A = f1() - 2 && A = f2() - 3 && A = f3() - 4))
		...

which I consider to be in the Canonical Obfuscated Form.

>Mixing imperatives with expressions accords well with the style of natural
>language (as opposed to a purely logical style), and thus can read better.

Fair enough. No one (as far as I know) has objected to this style as long
as the programmer's intent is unambiguous.

>This especially goes for the logical operators, which actually translate
>better as natural language connectives (with all its temporal connotations)
>than pure logic connectives (e.g. and = and then).

>Witness this classic (I saw something like it in YACC source):

>                   (A = new-object()) || Error(A);

>Translation: "Make a new object or bust."

This style of "hack" actually comes from UNIX shells, where the || and &&
have precisely those semantics. However, in C you might run afoul because
the datatype of "new-object()" and "Error()" are (might be) different. Some
compilers object to this.

>Or...	    (Op = FindOp(S)) && return Op->Type ||
>	    (Sym = NewSym(S)) && return Sym->Index;

Same deal. In fact, I seriously doubt that this is legal C at all, since
"return foo" is not an expression in C; it's a control statement.

If I *had* to code the above using a single statement, I'd do it so:

	return ((Op = FindOp(S)) != NULL)
		? Op->Type
		: (((Sym = NewSym(S)) != NULL) ? Sym->Index : NULL);

but I'd much *rather* type

	if ((Op = FindOp(s)) != NULL)
		return Op->Type;
	else if ((Sym = NewSym(s)) != NULL)
		return Sym->Index;
	else
		return NULL;