Velocity Reviews > C doubt

# C doubt

Vincenzo Mercuri
Guest
Posts: n/a

 07-01-2010
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
Guest
Posts: n/a

 07-01-2010
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
Guest
Posts: n/a

 07-01-2010
Il 02/07/2010 6.24, Ben Bacarisse ha scritto:
> Ian Collins<(E-Mail Removed)> 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

Ian Collins
Guest
Posts: n/a

 07-02-2010
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

Eric Sosman
Guest
Posts: n/a

 07-02-2010
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
http://www.velocityreviews.com/forums/(E-Mail Removed)lid

Ben Bacarisse
Guest
Posts: n/a

 07-02-2010
Ian Collins <(E-Mail Removed)> 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.

Ian Collins
Guest
Posts: n/a

 07-02-2010
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!

--
Ian Collins