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))
1. As long as K&R precedences still hold you don't need the inner >parentheses; '<' and '<=' has higher precedence than '&' and '&&'.
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
and probably & has no real disadvantages
(i mean no
bigger that the intention that && should be use for boolean - which
probably comes from later c not oryginal young c
so i probably plan to stick to &
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
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
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
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.
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
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))
1. As long as K&R precedences still hold you don't need the inner
parentheses; '<' and '<=' has higher precedence than '&' and '&&'.
While true, the parenthesis can be helpful to the reader
and have no adverse effects.
On 28/03/2024 15:14, Scott Lurndal wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
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))
1. As long as K&R precedences still hold you don't need the inner
parentheses; '<' and '<=' has higher precedence than '&' and '&&'.
While true, the parenthesis can be helpful to the reader
and have no adverse effects.
A couple of space characters would also not go amiss in aiding the reader.
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
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
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
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.
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
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))
1. As long as K&R precedences still hold you don't need the inner
parentheses; '<' and '<=' has higher precedence than '&' and '&&'.
While true, the parenthesis can be helpful to the reader
and have no adverse effects.
scott@slp53.sl.home (Scott Lurndal) writes:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
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))
1. As long as K&R precedences still hold you don't need the inner
parentheses; '<' and '<=' has higher precedence than '&' and '&&'.
While true, the parenthesis can be helpful to the reader
and have no adverse effects.
Certainly extra parentheses can be helpful to some readers.
Considered as a question of fact, the proposition that extra
parentheses have no adverse effects is false. It may be the
case that the adverse effects are thought to be unimportant
relative to some proposed benefit, but that is a question of
opinion rather than a question of fact.
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
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))
1. As long as K&R precedences still hold you don't need the inner
parentheses; '<' and '<=' has higher precedence than '&' and '&&'.
While true, the parenthesis can be helpful to the reader
and have no adverse effects.
tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
i was unable ro remember that
Groovy hepcat fir was jivin' in comp.lang.c on Wed, 27 Mar 2024 10:35
pm. It's a cool scene! Dig it.
tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
i was unable ro remember that
You're forgetting that && is a so-called "short circuit" operator. If
the left operand is false, then the right operand is not evaluated.
This makes little difference in this particular case; but what if you
had something like this instead?
while(some_function() < p && some_other_function() <= r)
Here some_other_function() will not be called if the some_function()
call returns a value >= p.
Tim Rentsch wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
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))
1. As long as K&R precedences still hold you don't need the inner
parentheses; '<' and '<=' has higher precedence than '&' and '&&'.
While true, the parenthesis can be helpful to the reader
and have no adverse effects.
Certainly extra parentheses can be helpful to some readers.
Considered as a question of fact, the proposition that extra
parentheses have no adverse effects is false. It may be the
case that the adverse effects are thought to be unimportant
relative to some proposed benefit, but that is a question of
opinion rather than a question of fact.
what a lamas you are ...
its quite oposite it is using parenthesis and && instead of & and ||
insetad | makes c source code lost its character - its generaly weird
world that i noticed it recenty not 20 years ago
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))
1. As long as K&R precedences still hold you don't need the inner parentheses; '<' and '<=' has higher precedence than '&' and '&&'.
2. In this case where you compare predicate expressions that
evaluate to '0' and '1' on both sides of '&' and '&&' respectively
these expressions are (while not the same) equivalent _here_.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 919 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 47:13:18 |
| Calls: | 12,183 |
| Calls today: | 3 |
| Files: | 186,524 |
| Messages: | 2,236,092 |