Re: while(T[l]<p & l<=r)

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.