From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_00,INVALID_MSGID,
	MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 11390f,4c42ac518eba0bbe
X-Google-Attributes: gid11390f,public
X-Google-Thread: 109fba,4c42ac518eba0bbe
X-Google-Attributes: gid109fba,public
X-Google-Thread: 103376,4c42ac518eba0bbe
X-Google-Attributes: gid103376,public
X-Google-Thread: 1014db,4c42ac518eba0bbe
X-Google-Attributes: gid1014db,public
From: wtanksle@sdcc10.ucsd.edu (William Tanksley)
Subject: Re: Programming language vote - results
Date: 1997/11/25
Message-ID: <65di3v$730$1@news1.ucsd.edu>#1/1
X-Deja-AN: 292814511
References: <3470EF6E.F74@lysator.liu.se>
 <64qsf0$ccc@dfw-ixnews11.ix.netcom.com> <347440AD.35DF@idt.net>
Organization: University of California, San Diego
Newsgroups: comp.lang.ada,comp.lang.apl,comp.lang.c,comp.lang.c++
Date: 1997-11-25T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <347440AD.35DF@idt.net> trs@idt.net writes:
>[big snip]

>> > Simple example from real life:

>> > if (call_this() || call_that());

>> I find myself using a construct like this a lot recently (snipped directly
>> from code I'm working on right now):

>> if(!to && !(to = malloc(sizeof *to)))) return(NULL);

>All of these constructs are flat out wrong. As far as I can remember,
>neither C or C++ guarantees that the clauses in a condition will be
>evaluated in the order you wrote them. IOW,

According to the ANSI standard and K&R, as well as universal prior
practice, the boolean logical operators are short-circuiting.  This means
that they MUST exectute in order.  In fact, this is required explicitly by
ANSI and K&R.

>The malloc example *probably* has enough parentheses to force it to work
>in the right order but the fact is that the code is obscure at best and
>wrong at worst. It is also no more efficient when compiled than the
>equivalent construct:

It'll work, so long as the library returns zeroes for nulls.  I personally
find it more readable than its stretched alternative, although for most
other purposes I'd use the stretch.

>if (!call_this())
>  call_that();

>Which, incidentally, is one *less* key stroke if you use a tab for the
>indent. Count 'em - I added four and deleted 5.

But then, I use an editor which is made to cut down on such keystrokes.
But who's counting.

>I would not accept this code at a walkthrough.

I'd have to see the surrounding design -- the malloc example looks
dismaying, but there might be a reason which I can't imagine to not know
and not care whether a pointer was initialized.

The if( this() || that() ); example I would toss right out -- but then
I've NEVER seen that written anywhere.  this() || that(); works exactly as
well, and doesn't tempt the code maintainer to assume that the semicolon
was a typo.

It's worth noting that using the short circuiting of 'or' is very common
in many languages.  Note some of the nicer aspects of Perl: "open file or
die".  Now THAT'S an idiom -- and me a good Python man :).

>Terry Richards

-Billy