Path: ...!weretis.net!feeder8.news.weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: fir <fir@grunge.pl>
Newsgroups: comp.lang.c
Subject: Re: while(T[l]<p & l<=r)
Date: Thu, 28 Mar 2024 18:12:44 +0100
Organization: i2pn2 (i2pn.org)
Message-ID: <uu48e7$3bg7g$1@i2pn2.org>
References: <uu109u$3798b$1@i2pn2.org> <uu3kqb$3i23g$1@dont-email.me> <uu3n7d$3aoj9$1@i2pn2.org> <uu4269$3lf5i$1@dont-email.me> <uu45rq$3bcok$1@i2pn2.org> <uu46ng$3ml9c$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 28 Mar 2024 17:12:42 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3522800"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="+ydHcGjgSeBt3Wz3WTfKefUptpAWaXduqfw5xdfsuS0";
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24
In-Reply-To: <uu46ng$3ml9c$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 4471
Lines: 94

bart wrote:
> On 28/03/2024 16:28, fir wrote:
>> Janis Papanagnou wrote:
>>> 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.
>>>
>>
>> how, if string ate empty then the pionters are nulls to
>> null&null should work ok imo
>
> Aren't x and y integers? An empty string is presumably "" (not NULL) and
> length("") should be 0.
>
>>> 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.)
>
>> becouse this && is ugly i think the addition of && is kinda error
>> in language
>
> Of all the ugly things in C, you have to pick on &&? In any case, that's
> the correct operator to use here, since && is quite different from &:
>
>      if (length(s) & length(t))
>
>      if (length(s) && length(t))
>
> Suppose s is "AB" and t is "ABCD". Then the version using & will do 2 &
> 4 which is zero: so FALSE.
>
> The version using && will be 2 && 4 which is 1, so TRUE, a completely
> different result.
>
> Also, if s was "", then the version using && short-circuits, so it won't
> bother evaluating length(t); it is more efficient.
>
> Also, as you've discovered, & has a different and less suitable
> precedence compared to &&.
>
>
> If you really hate '&&' then try including <iso646.h>. Now you can do this:
>
>      if (length(s) and length(t))
>
> But let me guess; that's too long-winded? 'A and B' instead of 'A&&B'
> because 'and' needs that white space.

should be A&B and everything looks liek it should

thsoe with length are weird programming i dont use it,
using & is not totally proper taking c history but && for me is also not 
fully proper taking c 'style' and & i find just better