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

bart wrote:

On 28/03/2024 17:12, fir wrote:

bart wrote:

>

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

>
You haven't read my post properly have you?
>
& and && do quite different things; I listed 3 major ways in which they
differ.
>
Here's another:
>
     float x=k, y=k;
     if (x && y)           // this will work as expected
     if (x & y)            // this won't compile
>

i dont use it this way - not this one with length ..literally never used it this way -
probably all teh usecases i use it the & will fit (not sure though but this can be seen)

>
>

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

>
OK. You can make & work a bit like && if you turn:
>
     A && B
>
where A and B are arbitrary expressions, into:
>
    !!(A) & !!(B)
>
But you still won't get short-circuit behaviour.
>