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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC 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: 1014db,4c42ac518eba0bbe
X-Google-Attributes: gid1014db,public
X-Google-Thread: 109fba,4c42ac518eba0bbe
X-Google-Attributes: gid109fba,public
X-Google-Thread: 103376,4c42ac518eba0bbe
X-Google-Attributes: gid103376,public
From: Terry Richards <trs@idt.net>
Subject: Re: Programming language vote - results
Date: 1997/11/20
Message-ID: <347440AD.35DF@idt.net>#1/1
X-Deja-AN: 291003756
References: <343fbb5a.0@news.iprolink.ch> <34466EB4.3381@dynamite.com.au>
 <6275dt$agm$3@news.on> <344BCED0.2D51@dynamite.com.au>
 <62tpap$7gh$1@darla.visi.com> <3470EF6E.F74@lysator.liu.se>
 <64qsf0$ccc@dfw-ixnews11.ix.netcom.com>
Organization: Terry Richards Software
Reply-To: trs@idt.net
Newsgroups: comp.lang.ada,comp.lang.apl,comp.lang.c,comp.lang.c++
Date: 1997-11-20T00:00:00+00:00
List-Id: <comp.lang.ada>


[big snip]

> > Simple example from real life:
> 
> > if (call_this() || call_that());
> 
> > Valid, yes. Better than
> 
> > if (!call_this()) call_that();
> 
> > or more clear forms in other languages?
> > Some people actually think so.
> 
> 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);
> 
> For 'verbose' code this would be written:
> 
> if(!to) {
>         if(!to = malloc(sizeof *to)) {
>                 return(NULL);
>         }
> }
> 
> I find this unacceptable. The first form is understood well enough anyway:
> If 'to' is not valid and an attempt to make 'to' valid fails, return an error.
> 
> The
> 
> if(foo() || bar())
> 
> construct may seem obfuscated and weird to you, it is the way the logic of
> some people's minds work. 

[more snippage]

Guys,

I'm not sure who wrote what here so I've removed all the names.

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,

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

could compile as if it where written:

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

which could have different results.

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:

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.

I would not accept this code at a walkthrough.

-- 
Terry Richards
Terry Richards Software