|
|
 |
 |
 |
 |
Why does the value get discarded in this case?
When I have:
int main(void)
{
int x = 256;
x>>8;
printf("The value is: %d\n", x);
return 0;
}
I get:
[cdalten@localhost ~]$ gcc -g -Wall seq.c -o seq
seq.c: In function 'main':
seq.c:6: warning: statement with no effect
[cdalten@localhost ~]$ ./seq
The value is: 256
However, when I change x from x>>8 to x++
#include <stdio.h>
int main(void)
{
int x = 256;
x++;
printf("The value is: %d\n", x);
return 0;
}
I get:
[cdalten@localhost ~]$ gcc -g -Wall seq.c -o seq
[cdalten@localhost ~]$ ./seq
The value is: 257
The question is, how come something like x>>8 discards the value right
away, but x++ doesn't?
Chad said:
<snip>
> The question is, how come something like x>>8 discards the value right
> away, but x++ doesn't?
It does. The difference is that x++ has a side-effect, which x>>8
doesn't, and the compiler considers it plausible that you wrote x++ not
for its value but for its side-effect, so it doesn't produce a
diagnostic message in the x++ case.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Chad wrote: > int main(void) > { > int x = 256; > x>>8; > printf("The value is: %d\n", x);
> return 0;
> }
> I get:
> [cdalten@localhost ~]$ gcc -g -Wall seq.c -o seq
> seq.c: In function 'main':
> seq.c:6: warning: statement with no effect
shifts it 8 places to the right, and throws the
result away.
> int main(void) > { > int x = 256; > x++; > printf("The value is: %d\n", x);
> return 0;
> }
the original value of `x`, and also arranges that `x`
is incremented.
> The question is, how come something like x>>8 discards the value right
> away, but x++ doesn't?
`x++` /does/ discard its value right away, the same as `x>>8` does.
However, the /increment operation/ is a side-effect, not a value,
and happens regardless.
--
"There's a doorway where there was a wall" /Master Humpries Clock/
Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
In article <1181135268.331964.274@o5g2000hsb.googlegroups.com>,
Chad <cdal @gmail.com> wrote: >The question is, how come something like x>>8 discards the value right >away, but x++ doesn't?
It gives you the value of 8, shifted right 8 places. It doesn't
shift x itself.
x>>=8 does what I think you are expecting.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
What's the rationale behind having something like x>>8 not having a
side-effect, but somthing like, x++ having a side effect?
In article <1181136264.990367.254@p77g2000hsh.googlegroups.com>,
Chad <cdal @gmail.com> wrote: >What's the rationale behind having something like x>>8 not having a >side-effect, but somthing like, x++ having a side effect?
the repeated >? In fact >> is like +, -, *, and /, none of which
have side effects.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Chad wrote:
> What's the rationale behind having something like x>>8 not having a
> side-effect, but somthing like, x++ having a side effect?
`x >> 8` is like `x + 1`. It has no side-effect because if it did,
expressions would be updating their operands all over the place.
Ikk.
`x++` has a side-effect because that's what it's /for/; to provide
the value of a variable and to update it, to make common combinations
of operations more compact (and maybe, in the old days, more efficient).
An expression like `a[i++]` allows you to get at an element of an
array /and/ advance the index to the next position, all in one go.
Otherwise you'd have to find somewhere to put the increment, `i += 1`.
Opinions on whether this kind of elegant compactness is a good idea
are rumoured to vary. As with most programming languages features,
it's possible to overdo things, and it's possible to misunderstand
what such expressions actually /mean/ and where the language crouches
ready to pull the rug out from under your feet, giggling like an
insane ferret on nitrous oxide.
--
The shortcuts are all full of people using them.
Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England
On 6 Jun, 14:38, Chris Dollin <chris.dol@hp.com> wrote:
[snip]
>... giggling like an insane ferret on nitrous oxide.
What a charming image - may I reuse it, please?
Chad wrote: ... snip ...
> The question is, how come something like x >> 8 discards the value
> right away, but x++ doesn't?
on expressions, and on the action of the ++ operator.
--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net
--
Posted via a free Usenet account from http://www.teranews.com
Chris Dollin <chris.dol @hp.com> writes: > Chad wrote: >> int main(void) >> { >> int x = 256; >> x>>8; >> printf("The value is: %d\n", x);
>> return 0;
>> }
>> I get:
>> [cdalten@localhost ~]$ gcc -g -Wall seq.c -o seq
>> seq.c: In function 'main':
>> seq.c:6: warning: statement with no effect
> The shift operation `x >> 8` takes the value of `x`,
> shifts it 8 places to the right, and throws the
> result away.
Um, that's not quite the way I'd put it.
The expression x>>8 yields the value of x right-shifted by 8 bits.
Throwing away the result isn't a feature of the ">>" operator; the
result is thrown away because you (the OP) asked for it to be thrown
away, by using the expression as a statement (by adding the ';').
What x>>8 *doesn't* do is modify the value of x, just as the
equivalent x/256 doesn't modify the value of x. Similarly, 256>>8
doesn't modify the value of 256, and 2+3 doesn't modify the value of 2
or 3.
The ++ operator, as numerous others have pointed out, has the *side
effect* of modifying the object that is its operand. That's why the
++ operator, unlike the >> operator, can *only* be applied to an
object (an lvalue); 256++ is illegal.
If you *want* to modify the value of x, replacing it with the result
of x>>8, you can write:
x = x>>8;
or, equivalently:
x >>= 8;
A couple of notes on the original program:
You're missing the "#include <stdio.h>". Your program may happen to
appear to work without it, but it's mandatory if you use printf or
anything else declared in <stdio.h>. (Somebody might point out that
you could drop the #include and declare the printf function yourself;
that's true, but it's a dumb thing to do.)
You can use bitwise operators, (<<, >>, &, |, ^) on signed integers if
you really want to, but it almost always makes much more sense to
apply them to unsigned integers. There are rules on how these
operators work on negative values, but I can't be bothered to look
them up.
--
Keith Thompson (The_Other_Keith) k@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
On Jun 6, 6:22 am, rich@cogsci.ed.ac.uk (Richard Tobin) wrote:
> In article <1181136264.990367.254 @p77g2000hsh.googlegroups.com>, > Chad <cdal@gmail.com> wrote:
> >What's the rationale behind having something like x>>8 not having a
> >side-effect, but somthing like, x++ having a side effect?
> Why do you think that x>>8 should be like x++? Is it because of
> the repeated >? In fact >> is like +, -, *, and /, none of which
> have side effects.
> -- Richard
> --
> "Consideration shall be given to the need for as many as 32 characters
> in some alphabets" - X3.4, 1963.
attempt to apply to UC-Berkeley and my manager at work asking me if I
was dumb, the whole x>>8 vs x++ sank in. Then as the accounting lady
at work was making more sexual advances at me, I realized I could have
saved myself posting on here had I given the whole x>>8 vs x++ more
than a millisecond of thought before giving up.
Chad wrote: ... snip ...
> Today, somewhere between me considering if I should make a third
> attempt to apply to UC-Berkeley and my manager at work asking me
> if I was dumb, the whole x>>8 vs x++ sank in. Then as the
> accounting lady at work was making more sexual advances at me, I
> realized I could have saved myself posting on here had I given
> the whole x>>8 vs x++ more than a millisecond of thought before
> giving up.
--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net
--
Posted via a free Usenet account from http://www.teranews.com
mark_blue @pobox.com wrote: > On 6 Jun, 14:38, Chris Dollin <chris.dol @hp.com> wrote: > [snip] >>... giggling like an insane ferret on nitrous oxide. > What a charming image - may I reuse it, please?
--
"It was the first really clever thing the King had said that day."
/Alice in Wonderland/
Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN
Keith Thompson wrote: > Chris Dollin <chris.dol @hp.com> writes: >> Chad wrote: >>> int main(void) >>> { >>> int x = 256; >>> x>>8; >>> printf("The value is: %d\n", x);
>>> return 0;
>>> }
>>> I get:
>>> [cdalten@localhost ~]$ gcc -g -Wall seq.c -o seq
>>> seq.c: In function 'main':
>>> seq.c:6: warning: statement with no effect
>> The shift operation `x >> 8` takes the value of `x`,
>> shifts it 8 places to the right, and throws the
>> result away.
> [...]
> Um, that's not quite the way I'd put it.
> The expression x>>8 yields the value of x right-shifted by 8 bits.
> Throwing away the result isn't a feature of the ">>" operator; the
> result is thrown away because you (the OP) asked for it to be thrown
> away, by using the expression as a statement (by adding the ';').
--
"Never ask that question!" Ambassador Kosh, /Babylon 5/
Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN
|
 |
 |
 |
 |
|
Add to del.icio.us |
Digg this |
Stumble it |
Powered by Megasolutions Inc