# C doubt

Discussion in 'C Programming' started by sangeeta chowdhary, Jul 1, 2010.

1. ### sangeeta chowdharyGuest

int arr[]={0,1,2,3,4};
int *p[]={arr,arr+1,arr+2,arr+3,arr+4};
int **p=p;

now,

ptr++;
*ptr++;
*++ptr

are same,means we are incrementing ptr everytime.

but ++*ptr is not incrementiing ptr . Why?

sangeeta chowdhary, Jul 1, 2010

2. ### Peter NilssonGuest

sangeeta chowdhary <> wrote:
> ptr++;
> *ptr++;
> *++ptr
>
> are same,means we are incrementing ptr everytime.
>
> but ++*ptr is not incrementiing ptr . Why?

A better question is why do you think it increments ptr?

Do you think (*ptr)++ should increment ptr as well?

If not, why not?

--
Peter

Peter Nilsson, Jul 1, 2010

3. ### Ike NaarGuest

In article <>,
sangeeta chowdhary <> wrote:
>int arr[]={0,1,2,3,4};
>int *p[]={arr,arr+1,arr+2,arr+3,arr+4};
>int **p=p;

This is an error; you probably meant ``int **ptr = p;''.

>now,
>
>ptr++;
>*ptr++;
>*++ptr
>
>are same,means we are incrementing ptr everytime.

There are subtle differences.
The first expression yields ptr, and, as a side effect, increments ptr.
The second expression yields *ptr, and, as a side effect, increments ptr.
The third expression yields *(ptr+1), and a a side effect, increments ptr.

So, all three statements increment ptr as a side effect, but each
statement produces a different value; it is only because you ignore
the produced values, that the three statements are effectively the same.

>but ++*ptr is not incrementiing ptr . Why?

++*ptr means ++(*ptr), that is, it increments *ptr,
the value that ptr points at, not ptr itself.

Ike Naar, Jul 1, 2010
4. ### sangeeta chowdharyGuest

On Jul 1, 12:07 pm, (Ike Naar) wrote:
> In article <>,
> sangeeta chowdhary  <> wrote:
>
> >int arr[]={0,1,2,3,4};
> >int *p[]={arr,arr+1,arr+2,arr+3,arr+4};
> >int **p=p;

>
> This is an error; you probably meant ``int **ptr = p;''.
>
> >now,

>
> >ptr++;
> >*ptr++;
> >*++ptr

>
> >are same,means we are incrementing ptr everytime.

>
> There are subtle differences.
> The first expression yields ptr, and, as a side effect, increments ptr.
> The second expression yields *ptr, and, as a side effect, increments ptr.
> The third expression yields *(ptr+1), and a a side effect, increments ptr..
>
> So, all three statements increment ptr as a side effect, but each
> statement produces a different value; it is only because you ignore
> the produced values, that the three statements are effectively the same.
>
> >but ++*ptr is not incrementiing ptr . Why?

>
> ++*ptr means ++(*ptr), that is, it increments *ptr,
> the value that ptr points at, not ptr itself.

Thanks a lot.

sangeeta chowdhary, Jul 1, 2010
5. ### sangeeta chowdharyGuest

On Jul 1, 11:59 am, Peter Nilsson <> wrote:
> sangeeta chowdhary <> wrote:
> > ptr++;
> > *ptr++;
> > *++ptr

>
> > are same,means we are incrementing ptr everytime.

>
> > but ++*ptr is not incrementiing ptr . Why?

>
> A better question is why do you think it increments ptr?
>
> Do you think (*ptr)++ should increment ptr as well?
>
> If not, why not?
>
> --
> Peter

Thanks a lot.

sangeeta chowdhary, Jul 1, 2010
6. ### Vincenzo MercuriGuest

sangeeta chowdhary wrote:
> int arr[]={0,1,2,3,4};
> int *p[]={arr,arr+1,arr+2,arr+3,arr+4};
> int **p=p;
>
> now,
>
> ptr++;
> *ptr++;
> *++ptr
>
> are same,means we are incrementing ptr everytime.
>
> but ++*ptr is not incrementiing ptr . Why?

*************************************
* A Frequently Unasked Memo *
*************************************

ptr, s, t being pointers (really?)

------------------------------------
1) ++*ptr == ++(*ptr)
------------------------------------

So, ++*s = ++*t; means:

*s = *s + 1; *t = *t + 1;
*t = *t + 1; or *s = *s + 1;
*s = *t; *s = *t;

------------------------------------
2) *++ptr == *(++ptr)
------------------------------------

So, *++s = *++t; means:

s = s + 1; t = t + 1;
t = t + 1; or s = s + 1;
*s = *t; *s = *t;

------------------------------------
3) *ptr++ == *(ptr++)
------------------------------------

So, *s++ = *t++; means:

*s = *t; *s = *t;
s = s + 1; or t = t + 1;
t = t + 1; s = s + 1;

------------------------------------
4) (*ptr)++ [no other way to get it]
------------------------------------

So, (*s)++ = (*t)++; means:

*s = *t; *s = *t;
*s = *s + 1; or *t = *t + 1;
*t = *t + 1; *s = *s + 1;

--
Vincenzo Mercuri

Vincenzo Mercuri, Jul 1, 2010
7. ### Vincenzo MercuriGuest

Il 02/07/2010 3.58, pete ha scritto:
> Vincenzo Mercuri wrote:
>>
>> sangeeta chowdhary wrote:
>>> int arr[]={0,1,2,3,4};
>>> int *p[]={arr,arr+1,arr+2,arr+3,arr+4};
>>> int **p=p;
>>>
>>> now,
>>>
>>> ptr++;
>>> *ptr++;
>>> *++ptr
>>>
>>> are same,means we are incrementing ptr everytime.
>>>
>>> but ++*ptr is not incrementiing ptr . Why?

>>
>> *************************************
>> * A Frequently Unasked Memo *
>> *************************************
>>
>> ptr, s, t being pointers (really?)
>>
>> ------------------------------------
>> 1) ++*ptr == ++(*ptr)
>> ------------------------------------
>>
>> So, ++*s = ++*t; means:
>>
>> *s = *s + 1; *t = *t + 1;
>> *t = *t + 1; or *s = *s + 1;
>> *s = *t; *s = *t;
>>
>> ------------------------------------
>> 2) *++ptr == *(++ptr)
>> ------------------------------------
>>
>> So, *++s = *++t; means:
>>
>> s = s + 1; t = t + 1;
>> t = t + 1; or s = s + 1;
>> *s = *t; *s = *t;
>>
>> ------------------------------------
>> 3) *ptr++ == *(ptr++)
>> ------------------------------------
>>
>> So, *s++ = *t++; means:
>>
>> *s = *t; *s = *t;
>> s = s + 1; or t = t + 1;
>> t = t + 1; s = s + 1;
>>
>> ------------------------------------
>> 4) (*ptr)++ [no other way to get it]
>> ------------------------------------
>>
>> So, (*s)++ = (*t)++; means:
>>
>> *s = *t; *s = *t;
>> *s = *s + 1; or *t = *t + 1;
>> *t = *t + 1; *s = *s + 1;

>
> Your meanings associated with these following statements:
> ++*s = ++*t;
> (*s)++ = (*t)++;
> suggest that you think that those statements can compile.
>

Wow! Indeed I thought!
I have been programming since November and I've never
noticed they were not lvalues! (I've never used them)
THANKS! (Shame on Me!)

--
Vincenzo Mercuri

Vincenzo Mercuri, Jul 1, 2010
8. ### Vincenzo MercuriGuest

Il 02/07/2010 3.58, pete ha scritto:
> Vincenzo Mercuri wrote:
>>
>> sangeeta chowdhary wrote:
>>> int arr[]={0,1,2,3,4};
>>> int *p[]={arr,arr+1,arr+2,arr+3,arr+4};
>>> int **p=p;
>>>
>>> now,
>>>
>>> ptr++;
>>> *ptr++;
>>> *++ptr
>>>
>>> are same,means we are incrementing ptr everytime.
>>>
>>> but ++*ptr is not incrementiing ptr . Why?

>>
>> *************************************
>> * A Frequently Unasked Memo *
>> *************************************
>>
>> ptr, s, t being pointers (really?)
>>
>> ------------------------------------
>> 1) ++*ptr == ++(*ptr)
>> ------------------------------------
>>
>> So, ++*s = ++*t; means:
>>
>> *s = *s + 1; *t = *t + 1;
>> *t = *t + 1; or *s = *s + 1;
>> *s = *t; *s = *t;
>>
>> ------------------------------------
>> 2) *++ptr == *(++ptr)
>> ------------------------------------
>>
>> So, *++s = *++t; means:
>>
>> s = s + 1; t = t + 1;
>> t = t + 1; or s = s + 1;
>> *s = *t; *s = *t;
>>
>> ------------------------------------
>> 3) *ptr++ == *(ptr++)
>> ------------------------------------
>>
>> So, *s++ = *t++; means:
>>
>> *s = *t; *s = *t;
>> s = s + 1; or t = t + 1;
>> t = t + 1; s = s + 1;
>>
>> ------------------------------------
>> 4) (*ptr)++ [no other way to get it]
>> ------------------------------------
>>
>> So, (*s)++ = (*t)++; means:
>>
>> *s = *t; *s = *t;
>> *s = *s + 1; or *t = *t + 1;
>> *t = *t + 1; *s = *s + 1;

>
> Your meanings associated with these following statements:
> ++*s = ++*t;
> (*s)++ = (*t)++;
> suggest that you think that those statements can compile.
>

Just a question (for my personal benefit, in order to understand)
why they are not lvalues?

--
Vincenzo Mercuri

Vincenzo Mercuri, Jul 1, 2010
9. ### Vincenzo MercuriGuest

Il 02/07/2010 3.00, Vincenzo Mercuri ha scritto:
> Il 02/07/2010 3.58, pete ha scritto:
>> Vincenzo Mercuri wrote:
>>>
>>> sangeeta chowdhary wrote:
>>>> int arr[]={0,1,2,3,4};
>>>> int *p[]={arr,arr+1,arr+2,arr+3,arr+4};
>>>> int **p=p;
>>>>
>>>> now,
>>>>
>>>> ptr++;
>>>> *ptr++;
>>>> *++ptr
>>>>
>>>> are same,means we are incrementing ptr everytime.
>>>>
>>>> but ++*ptr is not incrementiing ptr . Why?
>>>
>>> *************************************
>>> * A Frequently Unasked Memo *
>>> *************************************
>>>
>>> ptr, s, t being pointers (really?)
>>>
>>> ------------------------------------
>>> 1) ++*ptr == ++(*ptr)
>>> ------------------------------------
>>>
>>> So, ++*s = ++*t; means:
>>>
>>> *s = *s + 1; *t = *t + 1;
>>> *t = *t + 1; or *s = *s + 1;
>>> *s = *t; *s = *t;
>>>
>>> ------------------------------------
>>> 2) *++ptr == *(++ptr)
>>> ------------------------------------
>>>
>>> So, *++s = *++t; means:
>>>
>>> s = s + 1; t = t + 1;
>>> t = t + 1; or s = s + 1;
>>> *s = *t; *s = *t;
>>>
>>> ------------------------------------
>>> 3) *ptr++ == *(ptr++)
>>> ------------------------------------
>>>
>>> So, *s++ = *t++; means:
>>>
>>> *s = *t; *s = *t;
>>> s = s + 1; or t = t + 1;
>>> t = t + 1; s = s + 1;
>>>
>>> ------------------------------------
>>> 4) (*ptr)++ [no other way to get it]
>>> ------------------------------------
>>>
>>> So, (*s)++ = (*t)++; means:
>>>
>>> *s = *t; *s = *t;
>>> *s = *s + 1; or *t = *t + 1;
>>> *t = *t + 1; *s = *s + 1;

>>
>> Your meanings associated with these following statements:
>> ++*s = ++*t;
>> (*s)++ = (*t)++;
>> suggest that you think that those statements can compile.
>>

>
> Just a question (for my personal benefit, in order to understand)
> why they are not lvalues?
>

modifiable lvalues (as compiler complains)

--
Vincenzo Mercuri

Vincenzo Mercuri, Jul 1, 2010
10. ### Vincenzo MercuriGuest

Il 02/07/2010 5.41, Ian Collins ha scritto:
> On 07/ 2/10 10:30 AM, Vincenzo Mercuri wrote:
>> Il 02/07/2010 3.58, pete ha scritto:
>>>
>>> Your meanings associated with these following statements:
>>> ++*s = ++*t;
>>> (*s)++ = (*t)++;
>>> suggest that you think that those statements can compile.
>>>

>>
>> Just a question (for my personal benefit, in order to understand)
>> why they are not lvalues?

>
> (*s)++ yields a value, not an object. For example if *s is 4, how can
> something be assigned to 5?
>

I am being a little confused.

doesn't *s++ yield a value?
*s first, and then increase s by 1.

by value, don't you mean a number (in this case)?

thanks anyway.
you made me want to open
my books again!

--
Vincenzo Mercuri

Vincenzo Mercuri, Jul 2, 2010
11. ### Vincenzo MercuriGuest

Il 02/07/2010 6.09, Eric Sosman ha scritto:
> On 7/1/2010 6:30 PM, Vincenzo Mercuri wrote:
>> Il 02/07/2010 3.58, pete ha scritto:
>>> [...]
>>> Your meanings associated with these following statements:
>>> ++*s = ++*t;
>>> (*s)++ = (*t)++;
>>> suggest that you think that those statements can compile.

>>
>> Just a question (for my personal benefit, in order to understand)
>> why they are not lvalues?

>
> Most C operators yield "free-floating" values, plain values
> that are derived from "stored values." You can write `y = x + 1',
> and all is well: the `+' operator inspects its two operands `x' and
> `1', and yields their sum, and the `=' operator can store that sum
> in the spot designated by the left-hand side. But you cannot write
> `x + 1 = y', although it looks mathematically identical: The addition
> operator inspects its operands `x' and `1' and yields their sum, but
> it's a "free-floating" value, not a variable in which the value of
> `y' could be stored. C's assignment operator is spelled `=', but it
> doesn't have the mathematical meaning of "equals," it has the C
> meaning of "assign."
>
> So, let's look at the two proposed assignments with this
> in mind:
>
> `++*s = ++*t': Each side is well-formed and well-defined.
> `++*s' is "the value of whatever s points at, incremented." That
> is, it's "something plus one," plus a side-effect. Just as you
> can't write `x + 1 = y', you can't write `this + 1 = that'.
>
> `(*s)++ = (*t)++' runs into a similar problem. The left-hand
> side is "the value of whatever s points at, and arrange for that
> thing to be incremented sometime soon." The value, once extracted,
> is again a "free-floating" value, not someplace you can store some
> other value. (If you could, when would the incrementation happen
> and what would it mean?)
>
> Many programming languages are like this: There's a way of
> referring to an object for the purpose of extracting its value,
> and another way of referring to it for the purpose of storing a
> new value. The latter purpose is usually limited in various ways:
> Loosely speaking, you can name the variable you want to store to,
> but can't at the same time derive a value. Or, in less high-flown
> terms, you can't write `a*x*x + b*x + c = 0' and expect to have a
> quadratic root extracted and assigned to `x'!
>

EUREKA. Yes. It definitely makes sense.
I don't think I would have ever
found such an explanation somewhere else.

--
Vincenzo Mercuri

Vincenzo Mercuri, Jul 2, 2010
12. ### Vincenzo MercuriGuest

Il 02/07/2010 6.24, Ian Collins ha scritto:
> On 07/ 2/10 11:14 AM, Vincenzo Mercuri wrote:
>> Il 02/07/2010 5.41, Ian Collins ha scritto:
>>> On 07/ 2/10 10:30 AM, Vincenzo Mercuri wrote:
>>>> Il 02/07/2010 3.58, pete ha scritto:
>>>>>
>>>>> Your meanings associated with these following statements:
>>>>> ++*s = ++*t;
>>>>> (*s)++ = (*t)++;
>>>>> suggest that you think that those statements can compile.
>>>>>
>>>>
>>>> Just a question (for my personal benefit, in order to understand)
>>>> why they are not lvalues?
>>>
>>> (*s)++ yields a value, not an object. For example if *s is 4, how can
>>> something be assigned to 5?
>>>

>>
>> I am being a little confused.
>>
>> doesn't *s++ yield a value?
>> *s first, and then increase s by 1.
>>
>> by value, don't you mean a number (in this case)?
>>
>> thanks anyway.
>> you made me want to open
>> my books again!

>
> Or read Eric's excellent response!
>

Done. Thanks, now I understood

--
Vincenzo Mercuri

Vincenzo Mercuri, Jul 2, 2010
13. ### Vincenzo MercuriGuest

Il 02/07/2010 6.24, Ben Bacarisse ha scritto:
> Ian Collins<> writes:
>
>> On 07/ 2/10 10:30 AM, Vincenzo Mercuri wrote:
>>> Il 02/07/2010 3.58, pete ha scritto:
>>>>
>>>> Your meanings associated with these following statements:
>>>> ++*s = ++*t;
>>>> (*s)++ = (*t)++;
>>>> suggest that you think that those statements can compile.
>>>>
>>>
>>> Just a question (for my personal benefit, in order to understand)
>>> why they are not lvalues?

>>
>> (*s)++ yields a value, not an object. For example if *s is 4, how can
>> something be assigned to 5?

>
> (nit: the value of (*s)++ is 4 when *s is 4)
>
> But *s also yields a value yet the expression happens to be an lvalue.
> Ultimately the answer is a matter of definition: the C standard says
> what forms of expression constitute lvalues and which do not. *s does
> and exp++ does not.
>
> Unlike 3+1 = 42; where there is no sane way in which 3+1 could be
> assigned to, ++ and -- must have a modifiable lvalue as an argument so
> there is a possible meaning for i++ = 42; (though not a useful one in
> this example): the lvalue of exp++ could be that of exp.
>
> The other thing that you can do with an lvalue is take its address, and
> &i++ could be given a meaning and it would not be entirely useless.
> Presumably the balance was held to be in favour of simplicity rather
> than permitting an occasionally useful shorthand.
>

Great. Thanks! It appears ever so clear.
Thank you Ben

--
Vincenzo Mercuri

Vincenzo Mercuri, Jul 2, 2010
14. ### Ian CollinsGuest

On 07/ 2/10 10:30 AM, Vincenzo Mercuri wrote:
> Il 02/07/2010 3.58, pete ha scritto:
>>
>> Your meanings associated with these following statements:
>> ++*s = ++*t;
>> (*s)++ = (*t)++;
>> suggest that you think that those statements can compile.
>>

>
> Just a question (for my personal benefit, in order to understand)
> why they are not lvalues?

(*s)++ yields a value, not an object. For example if *s is 4, how can
something be assigned to 5?

--
Ian Collins

Ian Collins, Jul 2, 2010
15. ### Eric SosmanGuest

On 7/1/2010 6:30 PM, Vincenzo Mercuri wrote:
> Il 02/07/2010 3.58, pete ha scritto:
>> [...]
>> Your meanings associated with these following statements:
>> ++*s = ++*t;
>> (*s)++ = (*t)++;
>> suggest that you think that those statements can compile.

>
> Just a question (for my personal benefit, in order to understand)
> why they are not lvalues?

Most C operators yield "free-floating" values, plain values
that are derived from "stored values." You can write `y = x + 1',
and all is well: the `+' operator inspects its two operands `x' and
`1', and yields their sum, and the `=' operator can store that sum
in the spot designated by the left-hand side. But you cannot write
`x + 1 = y', although it looks mathematically identical: The addition
operator inspects its operands `x' and `1' and yields their sum, but
it's a "free-floating" value, not a variable in which the value of
`y' could be stored. C's assignment operator is spelled `=', but it
doesn't have the mathematical meaning of "equals," it has the C
meaning of "assign."

So, let's look at the two proposed assignments with this
in mind:

`++*s = ++*t': Each side is well-formed and well-defined.
`++*s' is "the value of whatever s points at, incremented." That
is, it's "something plus one," plus a side-effect. Just as you
can't write `x + 1 = y', you can't write `this + 1 = that'.

`(*s)++ = (*t)++' runs into a similar problem. The left-hand
side is "the value of whatever s points at, and arrange for that
thing to be incremented sometime soon." The value, once extracted,
is again a "free-floating" value, not someplace you can store some
other value. (If you could, when would the incrementation happen
and what would it mean?)

Many programming languages are like this: There's a way of
referring to an object for the purpose of extracting its value,
and another way of referring to it for the purpose of storing a
new value. The latter purpose is usually limited in various ways:
Loosely speaking, you can name the variable you want to store to,
but can't at the same time derive a value. Or, in less high-flown
terms, you can't write `a*x*x + b*x + c = 0' and expect to have a
quadratic root extracted and assigned to `x'!

--
Eric Sosman
lid

Eric Sosman, Jul 2, 2010
16. ### Ben BacarisseGuest

Ian Collins <> writes:

> On 07/ 2/10 10:30 AM, Vincenzo Mercuri wrote:
>> Il 02/07/2010 3.58, pete ha scritto:
>>>
>>> Your meanings associated with these following statements:
>>> ++*s = ++*t;
>>> (*s)++ = (*t)++;
>>> suggest that you think that those statements can compile.
>>>

>>
>> Just a question (for my personal benefit, in order to understand)
>> why they are not lvalues?

>
> (*s)++ yields a value, not an object. For example if *s is 4, how can
> something be assigned to 5?

(nit: the value of (*s)++ is 4 when *s is 4)

But *s also yields a value yet the expression happens to be an lvalue.
Ultimately the answer is a matter of definition: the C standard says
what forms of expression constitute lvalues and which do not. *s does
and exp++ does not.

Unlike 3+1 = 42; where there is no sane way in which 3+1 could be
assigned to, ++ and -- must have a modifiable lvalue as an argument so
there is a possible meaning for i++ = 42; (though not a useful one in
this example): the lvalue of exp++ could be that of exp.

The other thing that you can do with an lvalue is take its address, and
&i++ could be given a meaning and it would not be entirely useless.
Presumably the balance was held to be in favour of simplicity rather
than permitting an occasionally useful shorthand.

--
Ben.

Ben Bacarisse, Jul 2, 2010
17. ### Ian CollinsGuest

On 07/ 2/10 11:14 AM, Vincenzo Mercuri wrote:
> Il 02/07/2010 5.41, Ian Collins ha scritto:
>> On 07/ 2/10 10:30 AM, Vincenzo Mercuri wrote:
>>> Il 02/07/2010 3.58, pete ha scritto:
>>>>
>>>> Your meanings associated with these following statements:
>>>> ++*s = ++*t;
>>>> (*s)++ = (*t)++;
>>>> suggest that you think that those statements can compile.
>>>>
>>>
>>> Just a question (for my personal benefit, in order to understand)
>>> why they are not lvalues?

>>
>> (*s)++ yields a value, not an object. For example if *s is 4, how can
>> something be assigned to 5?
>>

>
> I am being a little confused.
>
> doesn't *s++ yield a value?
> *s first, and then increase s by 1.
>
> by value, don't you mean a number (in this case)?
>
> thanks anyway.
> you made me want to open
> my books again!