Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: while(T[l]<p & l<=r)
Date: Thu, 28 Mar 2024 16:26:00 +0100
Organization: A noiseless patient Spider
Lines: 56
Message-ID: <uu4269$3lf5i$1@dont-email.me>
References: <uu109u$3798b$1@i2pn2.org> <uu3kqb$3i23g$1@dont-email.me>
 <uu3n7d$3aoj9$1@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 28 Mar 2024 15:26:02 +0100 (CET)
Injection-Info: dont-email.me; posting-host="155435c3f40053ae5c3f5cbd325b2209";
	logging-data="3849394"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18lgEyRLfSAgzmJaKQ5AXCT"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:3NzJnIVnlMIljc20f1SzGTzUUVI=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <uu3n7d$3aoj9$1@i2pn2.org>
Bytes: 2985

On 28.03.2024 13:18, fir wrote:
> Janis Papanagnou wrote:
>> On 27.03.2024 12:35, fir wrote:
>>> tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
>>
>> [...] If
>> you don't want to operate on bits but want to express a boolean
>> conjunction you should use '&&', though.
> 
> [...]
> 
> hovever i wopuld disagre to use "&&" instead "&" then
> && look much worse

(Well, I think that '+' looks much worse than '*', but in
math expressions I use the _appropriate_ operator anyway.)

Mind that '&' is *not* a syntactical variant of '&&'...

> and probably & has no real disadvantages

it is different to '&&', it has another semantic! As said,
it's just by context-coincidence that it's equivalent _here_.

> (i mean no
> bigger that the intention that && should be use for boolean - which
> probably comes from later c not oryginal young c

Original K&R C had '&' for bit-operations and '&&' for boolean
operations.

While, say, 'x<y & u<v' works effectively as 'x<y && u<v' (as
said, because of the evaluations to 0 and 1, general boolean
predicates, like 'p() & q()' is not the same as 'p() && q()',
even if you can use 'p()' and 'q()' in 'if'-conditions as per
the C semantics of booleans (or integers used as booleans).

You often see code like,say, 'x=length(s); y=length(t);' and
compare non-emptiness of the strings with 'if (x)' or with
'if (y)'. If you combine that condition by 'if (x & y)' you
will get wrong results, but 'if (x && y)' would be correct.

'&' is for bit-operations in scalars, '&&' is for booleans
(for logical operations, bool x bool -> bool).

> 
> so i probably plan to stick to &

But why stick to a bit-value operator where you want a
boolean logic operator? - You just confuse readers of your
code and unnecessarily introduce error-prone code.

(But you can of course do as you like.)

Janis