pointers question
neeraj
why ++*p increments the value and *p++ increments the address pointed
by p.
can void pointer be treated as null pointer ?
Morris Keesan
>
> why ++*p increments the value
because *p is the value.
> and *p++ increments the address pointed by p.
It doesn't increment "the address pointed by p", it increments p, that is
it increments the address *contained in* p. Because of operator
precedence.
The ++ operator has higher precedence than the unary * operator.
> can void pointer be treated as null pointer ?
A pointer of type (void *) can be a null pointer.
A valid implementation-defined value of the NULL macro is ((void *)0).
--
Morris Keesan -- mke...@post.harvard.edu
Joe Wright
> why ++*p increments the value and *p++ increments the address pointed
> by p.
>
> can void pointer be treated as null pointer ?
Only if its value is NULL.
--
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."
Nobody
> why ++*p increments the value and *p++ increments the address pointed
> by p.
*p++ is equivalent to *(p++), i.e. post-increment the pointer
++*p is equivalent to ++(*p), i.e. pre-increment the location
referenced by the pointer.
The second one should be obvious, but the first one requires knowing C's
operator precedence (postfix ++ has higher precedence than unary *).
When * and ++ are on opposite sides of the variable, the fact that
postfix ++ has higher precedence than unary * matters. For consecutive
unary prefix operators, there's only one possible interpretation (i.e.
from inside to outside, i.e. right to left).
In the "*p++" case, you are likely to want "*(p++)" (i.e. postincrement
addresssing) far more often than "(*p)++" (increment memory location). If
the precedence was the other way around, you'd need to use many more
parentheses.
annalissa
just go through precedence tables you will understand why ?
BTW h>W for you
how will ++*p++ be evaluated ?
neeraj
> just go through precedence tables you will understand why ?
> BTW h>W for you
> how will ++*p++ be evaluated ?
this will first increment the value then increment the address
contained in p.
something like this (++*p)++
Ben Bacarisse
No. For one thing ++*p++ is parsed as if it were ++(*(p++)). Postfix
operators bind more tightly than prefix ones.
Secondly, the expression (++*p)++ can't do what you say is does.
Let's look at the types. If p is of type T *, then *p is of type T
and so are both ++*p and (++*p)++. Worse, the result of ++ is not an
lvalue so you can't apply the second ++ to it. In the same way, you
can't write:
++i = 42
Your compiler should tell you about this.
--
Ben.
annalissa
> neeraj <neeraj1...@gmail.com> writes:
> > On Dec 15, 1:50 am, annalissa <aark...@gmail.com> wrote:
> >> just go through precedence tables you will understand why ?
> > i will .
> >> BTW h>W for you
>
> >> how will ++*p++ be evaluated ?
>
> > this will first increment the value then increment the address
> > contained in p.
>
> > something like this (++*p)++
>
> No. For one thing ++*p++ is parsed as if it were ++(*(p++)). Postfix
> operators bind more tightly than prefix ones.
nope i don't think so , what about maximal munch rule ? , why it can't
be applied here ?
Hallvard B Furuseth
>On Dec 14, 6:23�pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>>neeraj <neeraj1...@gmail.com> writes:
>>>> how will ++*p++ be evaluated ?
>>
>>> this will first increment the value then increment the address
>>> contained in p.
>>
>>> something like this (++*p)++
>>
>> No. �For one thing ++*p++ is parsed as if it were ++(*(p++)). �Postfix
>> operators bind more tightly than prefix ones.
>
> nope i don't think so,
*Ask your compiler*. Try this, and then insert parentheses to force
the evaluation you think it should have, and compare.
#include <stdio.h>
int main() {
char s[] = "foo", *p = s, c = ++*p++;
printf("%c:%s.\n", c, p);
return 0;
}
> what about maximal munch rule ? , why it can't be applied here ?
For the same reason it can't be applied in e.g. 2+3*4, which is not
evaluated as (2+3)*4, or 1<2+3, which is not evaluated as (1<2)+3.
"maximal munch" is not what one normally wants in all cases, and so C
isn't defined that way. It's already been explained upthread why the
result would be nonsense in this case.
--
Hallvard
Dik T. Winter
> annalissa writes:
...
> > what about maximal munch rule ? , why it can't be applied here ?
>
> For the same reason it can't be applied in e.g. 2+3*4, which is not
> evaluated as (2+3)*4, or 1<2+3, which is not evaluated as (1<2)+3.
"maximal rule" is not about expressions, but about how sequences of symbols
are parsed to C tokens. That is: 'a+++b' parses as 'a ++ + b' and not as
'a + ++ b'.
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Seebs
It can, but all that applies to is tokens. Maximal munch is why that's
++ * p ++
not, say,
+ + * p + +
It has nothing to do with precedence.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!