is *ptr++ equivalent to *(ptr++)

Discussion in 'C Programming' started by junky_fellow@yahoo.co.in, Jul 19, 2005.

  1. Guest

    Is *ptr++ equivalent to *(ptr++) ?
     
    , Jul 19, 2005
    #1
    1. Advertising

  2. Rajan Guest

    Yes you are right.
     
    Rajan, Jul 19, 2005
    #2
    1. Advertising

  3. wrote:

    > Is *ptr++ equivalent to *(ptr++) ?


    Yes. In each case, the associativity is right-to-left and, in each case, the
    value seen by * is the old value of ptr, not the new value that it will
    have when ++ has completed its work.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    mail: rjh at above domain
     
    Richard Heathfield, Jul 19, 2005
    #3
  4. Guest

    wrote:
    > Is *ptr++ equivalent to *(ptr++) ?


    yes it is correct....
    one more

    ++*ptr == (*ptr)++
     
    , Jul 19, 2005
    #4
  5. S.Tobias Guest

    Richard Heathfield <> wrote:
    > wrote:
    >
    >> Is *ptr++ equivalent to *(ptr++) ?

    >
    > Yes. In each case, the associativity is right-to-left and, in each case, the


    I don't think "associativity" is the right word here, as they are
    unary operators. "Precedence" is more appropriate, I think.

    > value seen by * is the old value of ptr, not the new value that it will
    > have when ++ has completed its work.



    There's a rule of thumb for unary operators in C, first you read ones
    to the right, then ones to the left (unless, of cource, paretheses
    override this).

    A couple of (non-trivial) examples:
    *p++
    ++p;
    *p
    &a
    ++p->m
    (type*)p->m
    *p()

    (But I haven't really made sure that it always works; and `sizeof' is
    special.)

    --
    Stan Tobias
    mailx `echo LID | sed s/[[:upper:]]//g`
     
    S.Tobias, Jul 19, 2005
    #5
  6. Chris Dollin Guest

    wrote:

    >
    >
    > wrote:
    >> Is *ptr++ equivalent to *(ptr++) ?

    >
    > yes it is correct....
    > one more
    >
    > ++*ptr == (*ptr)++


    I hardly think so.

    --
    Chris "electric hedgehog" Dollin
    It's called *extreme* programming, not *stupid* programming.
     
    Chris Dollin, Jul 19, 2005
    #6
  7. Eric Guest

    Yes. See the details here:
    http://msdn.microsoft.com/library/d...s/vclang/html/_pluslang_c.2b2b_.operators.asp
    (google with "operator precedence" and "left to right" and "right to left"
    for more lists)

    Like you can see in the list, the post-increment operator will be executed
    first, if there are no brackets.

    The associativity for the indirection operator is right to left and for the
    post-increment operator left to right. But for this example this is not of
    any importance.

    Eric


    <> wrote in message
    news:...
    > Is *ptr++ equivalent to *(ptr++) ?
    >
     
    Eric, Jul 19, 2005
    #7
  8. Chris Dollin wrote:
    > wrote:
    >
    > >
    > >
    > > wrote:
    > >> Is *ptr++ equivalent to *(ptr++) ?

    > >
    > > yes it is correct....
    > > one more
    > >
    > > ++*ptr == (*ptr)++

    >
    > I hardly think so.
    >


    The two constructs are equivalent in the following scenarios:

    int *ptr = ...;
    int i;

    (void)++*ptr;
    (void)(*ptr)++;

    However, their behaviour is not the same when used like this:

    i = (*ptr)++;
    i = ++*ptr;

    --
    Vijay Kumar R. Zanvar
    Home Page - http://geocities.com/vijoeyz/
     
    Vijay Kumar R. Zanvar, Jul 19, 2005
    #8
  9. Chris Dollin Guest

    Vijay Kumar R. Zanvar wrote:

    >
    >
    > Chris Dollin wrote:
    >> wrote:
    >>
    >> >
    >> >
    >> > wrote:
    >> >> Is *ptr++ equivalent to *(ptr++) ?
    >> >
    >> > yes it is correct....
    >> > one more
    >> >
    >> > ++*ptr == (*ptr)++

    >>
    >> I hardly think so.
    >>

    >
    > The two constructs are equivalent in the following scenarios:
    >
    > int *ptr = ...;
    > int i;
    >
    > (void)++*ptr;
    > (void)(*ptr)++;
    >
    > However, their behaviour is not the same when used like this:
    >
    > i = (*ptr)++;
    > i = ++*ptr;


    Hence, they are not equivalent; you can't just use one in place
    of the other.

    --
    Chris "electric hedgehog" Dollin
    It's called *extreme* programming, not *stupid* programming.
     
    Chris Dollin, Jul 19, 2005
    #9
  10. Chris Dollin wrote:
    > Vijay Kumar R. Zanvar wrote:
    >
    > >
    > >
    > > Chris Dollin wrote:
    > >> wrote:
    > >>
    > >> >
    > >> >
    > >> > wrote:
    > >> >> Is *ptr++ equivalent to *(ptr++) ?


    [..]

    > Hence, they are not equivalent; you can't just use one in place
    > of the other.
    >


    Yes, you're quite correct. But for a learner, he/she must know the
    difference. Practically, these two construct should not be
    interchanged.

    > --
    > Chris "electric hedgehog" Dollin
    > It's called *extreme* programming, not *stupid* programming.
     
    Vijay Kumar R. Zanvar, Jul 19, 2005
    #10
  11. Chris Dollin Guest

    Vijay Kumar R. Zanvar wrote:

    > Chris Dollin wrote:
    >> Vijay Kumar R. Zanvar wrote:
    >>
    >> >
    >> >
    >> > Chris Dollin wrote:
    >> >> wrote:
    >> >>
    >> >> >
    >> >> >
    >> >> > wrote:
    >> >> >> Is *ptr++ equivalent to *(ptr++) ?

    >
    > [..]


    Your snipping is excessive; you've eliminated the thing we were
    talkign about and left in the thing we're /not/ talking about.

    The two things we - or, at least, I - were talking about were

    ++*ptr and (*ptr)++

    >> Hence, they are not equivalent; you can't just use one in place
    >> of the other.

    >
    > Yes, you're quite correct. But for a learner, he/she must know the
    > difference.


    Learners should learn the difference; experts already know the
    difference, to wit, that their results are different, by 1,
    because one is pre-increment and the other is post-increment.

    > Practically, these two construct should not be interchanged.


    Because they're not equivalent, yes. If one /doesn't care
    about the result/, they are - but in that case, I'd write
    them as

    *ptr += 1;

    which I think both better expresses the don't-care, and is
    less likely to lead to queries or arguments about precedence
    and associativity and order-of-evaluation.

    --
    Chris "electric hedgehog" Dollin
    It's called *extreme* programming, not *stupid* programming.
     
    Chris Dollin, Jul 19, 2005
    #11
  12. Guest

    S.Tobias wrote:
    > Richard Heathfield <> wrote:
    > > wrote:
    > >
    > >> Is *ptr++ equivalent to *(ptr++) ?

    > >
    > > Yes. In each case, the associativity is right-to-left and, in each case, the

    >
    > I don't think "associativity" is the right word here, as they are
    > unary operators. "Precedence" is more appropriate, I think.
    >


    But the precedence of *(indirection) and ++(post increment) operators
    is same. So, I think associativity should be the right word.
     
    , Jul 19, 2005
    #12
  13. S.Tobias Guest

    wrote:
    > S.Tobias wrote:
    >> Richard Heathfield <> wrote:
    >> > wrote:


    >> >> Is *ptr++ equivalent to *(ptr++) ?
    >> >
    >> > Yes. In each case, the associativity is right-to-left and, in each case, the

    >>
    >> I don't think "associativity" is the right word here, as they are
    >> unary operators. "Precedence" is more appropriate, I think.
    >>

    > But the precedence of *(indirection) and ++(post increment) operators
    > is same.


    No.

    unary-expr:
    postfix-expr
    unary-operator cast-expr

    unary-operator: one of
    & * + - ~ !

    cast-expr:
    unary-expr
    ( type-name ) cast-expr

    >So, I think associativity should be the right word.


    It makes no sense, associativity is a propoerty of binary operators.

    --
    Stan Tobias
    mailx `echo LID | sed s/[[:upper:]]//g`
     
    S.Tobias, Jul 19, 2005
    #13
  14. Eric Guest

    Hi

    The operator precedence is NOT the same. And yes, the associativity is
    different too.
    Please have a look at my link I posted earlier.

    Eric

    <> wrote in message
    news:...
    >
    >
    > S.Tobias wrote:
    >> Richard Heathfield <> wrote:
    >> > wrote:
    >> >
    >> >> Is *ptr++ equivalent to *(ptr++) ?
    >> >
    >> > Yes. In each case, the associativity is right-to-left and, in each
    >> > case, the

    >>
    >> I don't think "associativity" is the right word here, as they are
    >> unary operators. "Precedence" is more appropriate, I think.
    >>

    >
    > But the precedence of *(indirection) and ++(post increment) operators
    > is same. So, I think associativity should be the right word.
    >
     
    Eric, Jul 19, 2005
    #14
  15. S.Tobias wrote:

    > Richard Heathfield <> wrote:
    >> wrote:
    >>
    >>> Is *ptr++ equivalent to *(ptr++) ?

    >>
    >> Yes. In each case, the associativity is right-to-left and, in each case,
    >> the

    >
    > I don't think "associativity" is the right word here, as they are
    > unary operators. "Precedence" is more appropriate, I think.


    Not so. * and ++ have the same precedence, so the word is not useful in this
    context.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    mail: rjh at above domain
     
    Richard Heathfield, Jul 20, 2005
    #15
  16. S.Tobias wrote:

    > wrote:
    >> S.Tobias wrote:
    >>> Richard Heathfield <> wrote:
    >>> > wrote:

    >
    >>> >> Is *ptr++ equivalent to *(ptr++) ?
    >>> >
    >>> > Yes. In each case, the associativity is right-to-left and, in each
    >>> > case, the
    >>>
    >>> I don't think "associativity" is the right word here, as they are
    >>> unary operators. "Precedence" is more appropriate, I think.
    >>>

    >> But the precedence of *(indirection) and ++(post increment) operators
    >> is same.

    >
    > No.


    Wrong. They are the same.

    > unary-expr:
    > postfix-expr
    > unary-operator cast-expr
    >
    > unary-operator: one of
    > & * + - ~ !
    >
    > cast-expr:
    > unary-expr
    > ( type-name ) cast-expr


    That isn't particularly helpful. Of rather more explanatory power is the
    table on p53 of K&R, which shows us that * and ++ have the same precedence
    level, so the ordering within the statement becomes relevant - and that
    ordering is right-to-left for that particular precedence level.


    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    mail: rjh at above domain
     
    Richard Heathfield, Jul 20, 2005
    #16
  17. S.Tobias Guest

    Richard Heathfield <> wrote:
    > S.Tobias wrote:
    >> wrote:
    >>> S.Tobias wrote:
    >>>> Richard Heathfield <> wrote:
    >>>> > wrote:

    >>
    >>>> >> Is *ptr++ equivalent to *(ptr++) ?
    >>>> >
    >>>> > Yes. In each case, the associativity is right-to-left and, in each
    >>>> > case, the
    >>>>
    >>>> I don't think "associativity" is the right word here, as they are
    >>>> unary operators. "Precedence" is more appropriate, I think.
    >>>>
    >>> But the precedence of *(indirection) and ++(post increment) operators
    >>> is same.

    >>
    >> No.

    >
    > Wrong. They are the same.
    >
    >> unary-expr:
    >> postfix-expr
    >> unary-operator cast-expr
    >>
    >> unary-operator: one of
    >> & * + - ~ !
    >>
    >> cast-expr:
    >> unary-expr
    >> ( type-name ) cast-expr

    >
    > That isn't particularly helpful. Of rather more explanatory power is the
    > table on p53 of K&R, which shows us that * and ++ have the same precedence
    > level, so the ordering within the statement becomes relevant - and that
    > ordering is right-to-left for that particular precedence level.


    All right, I agree. There's nothing to argue about. I haven't
    looked at that table for a long time.

    I might not be a good pupil, but I have learned here in c.l.c that
    C does not actually define precedence, but rather the precedence
    is expressed in terms of syntax rules. What I tried to show is
    that whenever a unary and a post-fix operators meet, the post-fix
    one is evaluated first (which I guess is the same as what "right
    associative" means in that table, though I'm still not convinced
    that the choice of words was right).

    --
    Stan Tobias
    mailx `echo LID | sed s/[[:upper:]]//g`
     
    S.Tobias, Jul 20, 2005
    #17
  18. Guest

    Richard Heathfield <> wrote:
    >
    > That isn't particularly helpful. Of rather more explanatory power is the
    > table on p53 of K&R, which shows us that * and ++ have the same precedence
    > level, so the ordering within the statement becomes relevant - and that
    > ordering is right-to-left for that particular precedence level.


    The precedences shown in that table are not the same as the precedences
    implied by the grammar in the standard. It's of no practical
    consequence since, as you might expect given the source, the table
    produces the same result for all valid expressions, but it does have an
    impact on academic discussions such as this one. According to the
    standard, postfix ++ and -- do have higher precedence than unary *
    (which has the same precedence as prefix ++ and --; K&R's table give the
    prefix and postfix operators the same precedence and count on
    associativity to get the correct results).

    -Larry Jones

    OK, what's the NEXT amendment say? I know it's in here someplace. -- Calvin
     
    , Jul 20, 2005
    #18
  19. Tim Rentsch Guest

    writes:

    > Richard Heathfield <> wrote:
    > >
    > > That isn't particularly helpful. Of rather more explanatory power is the
    > > table on p53 of K&R, which shows us that * and ++ have the same precedence
    > > level, so the ordering within the statement becomes relevant - and that
    > > ordering is right-to-left for that particular precedence level.

    >
    > The precedences shown in that table are not the same as the precedences
    > implied by the grammar in the standard. It's of no practical
    > consequence since, as you might expect given the source, the table
    > produces the same result for all valid expressions, but it does have an
    > impact on academic discussions such as this one. According to the
    > standard, postfix ++ and -- do have higher precedence than unary *
    > (which has the same precedence as prefix ++ and --; K&R's table give the
    > prefix and postfix operators the same precedence and count on
    > associativity to get the correct results).


    Furthermore, the table is wrong (at least if it's the same table as the
    one I'm used to). The expression

    sizeof (int) - 1

    is parsed as

    (sizeof (int)) - 1

    not as

    sizeof ((int) (- 1))

    as the table implies.
     
    Tim Rentsch, Jul 20, 2005
    #19
  20. pete Guest

    Chris Dollin wrote:
    >
    > wrote:
    >
    > >
    > >
    > > wrote:
    > >> Is *ptr++ equivalent to *(ptr++) ?

    > >
    > > yes it is correct....
    > > one more
    > >
    > > ++*ptr == (*ptr)++

    >
    > I hardly think so.


    In contexts where the value of ptr isn't used,
    they can be equivalent.
    In short, they aren't equivalent.

    But, the expression
    ++*ptr == (*ptr)++
    is undefined.
    *ptr is modified twice with no sequence point.

    --
    pete
     
    pete, Jul 21, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sid
    Replies:
    5
    Views:
    1,110
  2. Heiko Vogel
    Replies:
    3
    Views:
    598
    Method Man
    Sep 14, 2004
  3. franco ziade

    const ptr to const ptr ?

    franco ziade, Feb 17, 2005, in forum: C Programming
    Replies:
    3
    Views:
    420
    franco ziade
    Feb 17, 2005
  4. G Fernandes
    Replies:
    9
    Views:
    627
    DHOLLINGSWORTH2
    Feb 27, 2005
  5. Jason

    difference between *ptr++ and ++*ptr ?

    Jason, May 15, 2005, in forum: C Programming
    Replies:
    19
    Views:
    6,663
    Chris Torek
    May 19, 2005
Loading...

Share This Page