Need Explanation on Lvalue Assignment for the following snippet
Pranav
#include<conio.h>
int main()
{
const int i=6;
int k = 9;
int a[i], *c = a, *v = a ;
a[2] = 9;
*c++ = *v++; // ( 1 ) This line does not generate any exception /
error
k++ = k++; // ( 2 ) But this line is generating
k++ = 6; // ( 3 ) This Also Generating
getch();
}
Now I know that you cannot assign a value to an expression; But why
does the above (1) expression not generating a exception/error/
warning? and (2) & (3) are generating as they are supposed to. Please
explain this.
Is this due to operator precedence in the case(1), ie the expression
access the value and then assign them and then increment the pointers
and move forward. Correct if I am wrong..,
(I am using DevC++ Compiler for testing)
Richard Heathfield
> #include<stdio.h>
> #include<conio.h>
> int main()
> {
> const int i=6;
> int k = 9;
> int a[i], *c = a, *v = a ;
> a[2] = 9;
>
> *c++ = *v++; // ( 1 ) This line does not generate any exception /
> error
Nevertheless, the behaviour of the statement, and therefore the program, is
undefined, because *v++ reads a[0], the value of which is indeterminate.
> k++ = k++; // ( 2 ) But this line is generating
This is not only a syntax error (because k++ is not an lvalue) but, even if
it were not a syntax error, it would generate undefined behaviour because
you're modifying (or rather, trying to modify!) a value twice between
consecutive sequence points.
> k++ = 6; // ( 3 ) This Also Generating
>
> getch();
> }
>
> Now I know that you cannot assign a value to an expression; But why
> does the above (1) expression not generating a exception/error/
> warning?
Because *c++ IS an lvalue! ++ has precedence over *, so it is the pointer,
not the object pointed to, whose value is incremented. As a side effect,
the old value of the pointer is dereferenced, yielding an object - ie an
lvalue - ie something you can store something in.
> and (2) & (3) are generating as they are supposed to. Please
> explain this.
> Is this due to operator precedence in the case(1),
Yes.
> ie the expression
> access the value and then assign them and then increment the pointers
> and move forward. Correct if I am wrong..,
Your conclusion is correct, but for the wrong reason. This *is* to do with
precedence, but *not* to do with order of evaluation. Precedence is to do
with which operators bind to which operands, not to do with the order in
which operations are carried out.
> (I am using DevC++ Compiler for testing)
Make sure you invoke it in C mode, then, because C is a different language
to C++. (If you're using C++, you'd be better off asking in
comp.lang.c++.)
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
pete
> #include<stdio.h>
> #include<conio.h>
> int main()
> {
> const int i=6;
> int k = 9;
> int a[i], *c = a, *v = a ;
> a[2] = 9;
>
> *c++ = *v++; // ( 1 ) This line does not generate any exception /
You're assigning a value to (*c) there.
There nothing wrong with that.
> error
> k++ = k++; // ( 2 ) But this line is generating
> k++ = 6; // ( 3 ) This Also Generating
Though (k++) has the same value
as (k) did before the increment,
(k++) is the result of an arithmetic operation.
A simpler example of the same problem, would be:
(k + 1) = 6;
(&k) is the address of (k), but (k + 1) doesn't have an address,
so there is no place to put the value of (6) into.
--
pete
Richard Heathfield
> Pranav wrote:
<snip>
>> const int i=6;
>> int k = 9;
>> int a[i], *c = a, *v = a ;
>> a[2] = 9;
>>
>> *c++ = *v++; // ( 1 ) This line does not generate any exception /
>
> You're assigning a value to (*c) there.
> There nothing wrong with that.
Look again! :-)
<snip>
pete
> pete said:
>
>> Pranav wrote:
> <snip>
>>> const int i=6;
>>> int k = 9;
>>> int a[i], *c = a, *v = a ;
>>> a[2] = 9;
>>>
>>> *c++ = *v++; // ( 1 ) This line does not generate any exception /
>> You're assigning a value to (*c) there.
>> There nothing wrong with that.
>
> Look again! :-)
I was just addressing the lvalue issue from the subject line.
The code has other problems too.
I read you other post in this thread.
I think you got them all.
--
pete
vipp...@gmail.com
He did not mention <conio.h> and getchr() not being defined by the
standard.
pete
Even though getchr() isn't defined by the standard,
I think you mean getch().
--
pete
Nick Keighley
> Pranav said:
>
> > #include<stdio.h>
> > #include<conio.h>
non-standard header
> > int main()
int main(void)
is better style
> > {
> > const int i=6;
> > int k = 9;
> > int a[i], *c = a, *v = a ;
"a" appears to be a C99 VLA (older versions of C
don't support variable length arrays)
> > a[2] = 9;
>
> > *c++ = *v++; // ( 1 ) This line does not generate any exception /
> > error
>
> Nevertheless, the behaviour of the statement, and therefore the program, is
> undefined, because *v++ reads a[0], the value of which is indeterminate.
as c and v point to the same thing wouldn't there be UB even if
a[0] was initialised?
#include <stdio.h>
int main (void)
{
int a [6] = {0};
int *c = a;
int *v = a;
*c++ = *v++; /* UB I believe */
return 0;
}
<snip>
--
Nick Keighley
vipp...@gmail.com
> vipps...@gmail.com wrote:
>
> > He did not mention <conio.h> and getchr() not being defined by the
> > standard.
>
> Even though getchr() isn't defined by the standard,
> I think you mean getch().
That's right.
Willem
) as c and v point to the same thing wouldn't there be UB even if
) a[0] was initialised?
)
) #include <stdio.h>
)
) int main (void)
) {
) int a [6] = {0};
) int *c = a;
) int *v = a;
)
) *c++ = *v++; /* UB I believe */
) return 0;
) }
Nope, that's not UB.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
Richard Heathfield
> On Sep 4, 11:19 am, pete <pfil...@mindspring.com> wrote:
<snip>
>> I think you got them all.
>
> He did not mention <conio.h> and getchr() not being defined by the
> standard.
That's true - I didn't. Feel free to do so yourself.
Richard Heathfield
> On 4 Sep, 09:11, Richard Heathfield <r...@see.sig.invalid> wrote:
>> Pranav said:
>>
>> > #include<stdio.h>
>> > #include<conio.h>
>
> non-standard header
<sigh> Yes, I know.
>
>> > int main()
>
> int main(void)
> is better style
True enough.
>
>> > {
>> > const int i=6;
>> > int k = 9;
>> > int a[i], *c = a, *v = a ;
>
> "a" appears to be a C99 VLA (older versions of C
> don't support variable length arrays)
Yes, but it's still legal C, if he's using a C99 compiler, which is not
beyond the bounds of possibility. Another indication that he might be is
that he's using BCPL-style comments.
>> > a[2] = 9;
>>
>> > *c++ = *v++; // ( 1 ) This line does not generate any exception /
>> > error
>>
>> Nevertheless, the behaviour of the statement, and therefore the program,
>> is undefined, because *v++ reads a[0], the value of which is
>> indeterminate.
>
> as c and v point to the same thing wouldn't there be UB even if
> a[0] was initialised?
No: ignoring the ++s for a while, it would simply be the equivalent of a[0]
= a[0]; which is perfectly legal. The ++s affect the pointers (which are
different objects), not the object to which they both point.
>
> #include <stdio.h>
Unnecessary header (since we're being picky). :-)
> int main (void)
> {
> int a [6] = {0};
> int *c = a;
> int *v = a;
>
> *c++ = *v++; /* UB I believe */
You believe wrong, for the reason stated.
<snip>
vipp...@gmail.com
> vipps...@gmail.com said:
>
> > On Sep 4, 11:19 am, pete <pfil...@mindspring.com> wrote:
>
> <snip>
>
> >> I think you got them all.
>
> > He did not mention <conio.h> and getchr() not being defined by the
> > standard.
>
> That's true - I didn't. Feel free to do so yourself.
I don't understand your reply, I did so. If my reply came out as
offensive, it was not my intention. I was not trying to correct you, I
had the genuine intentions of replying to the OP with a full post, but
after seeing yours, the only thing to add was that conio/getch is not
standard.
Pranav
Pranav
Antoninus Twink
> On Sep 4, 2:13 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> vipps...@gmail.com said:
>> > He did not mention <conio.h> and getchr() not being defined by the
>> > standard.
>>
>> That's true - I didn't. Feel free to do so yourself.
>
> but after seeing yours, the only thing to add was that conio/getch is
> not standard.
It's crystal clear that your intention was to be a prissy little
dickhead as usual. If the OP is writing a console program for Windows,
WHY IN THE HELL should he listen to your whining about non-"Standard"
functions THAT HE NEEDS TO USE?
Richard
It was blatantly obvious at an early stage that vippstar is only
interested in currying favour with the clique at each and every
opportunity.
Richard
Try reading the thread before offering advice. It saves a lot of clc
clique in fighting and tedious repeated answers.