C programming

[clogics]

hi iam sundar really want to clear C concepts please help me I got stuck in operators while I faced this question
main()
{
i=5,j=10;
i=i&=j&&10;
printf("%d %d",i,j);
}
what does &= does mean. And what is the logic means how to solve these problems efficiently.

[askcq]

j&&10 ...is logical AND
so the result is ONE

i&=j&&10 will be bitwise AND i and the result ONE
i.e., five AND ONE ...

[weaknessforcats]

hi iam sundar really want to clear C concepts please help me I got stuck in operators while I faced this question
main()
{
i=5,j=10;
i=i&=j&&10;
printf("%d %d",i,j);
}
what does &= does mean. And what is the logic means how to solve these problems efficiently.

Let's take this in pieces.

j && 10

is an expression using logical AND. Expressions are true or false. In C and C++ false is zero and true is not false. So, 5 is true and 10 is true so the exporession is true. The value of the expression is 1.

i& is bitwwise AND. A bitwise AND produces a 1 bit only if the the corresponding bits in the operands are both 1. In this case i is 5

00000101 <--- i
00000001 <----the value of j&&10
00000001 <--the result of the bitwise AND

i&= is the same bitwise AND but the result is put back into i. Based on the above, i noe has a value of 1.

i = i &= etc..

is pointless. i has already been changed by the & bitwise AND so this really is

i = i

[JosAH]

I apologize for being a partypooper again but still: changing an lvalue more than
once before a sequence point is reached results in undefined behaviour.

kind regards,

Jos

[weaknessforcats]

I apologize for being a partypooper again but still: changing an lvalue more than
once before a sequence point is reached results in undefined behaviour.

I don't think so in this case. I think this one has to go R-L.
[code=c]
i=i&=j&&10;
[/code]

&& precedence 13
&= precedence 16
= precedence 16 R-L

That means the && goes first.
That means &= goes next because = associates R-L
That means = goes last.

[JosAH]

I don't think so in this case. I think this one has to go R-L.

Nope, sorry; compare it with this one:

[code=cpp]
i= 42;
i+= i-= i*= i/= 1;
[/code]

Multiple changes to an lvalue before a sequence point is reached: *kaboom!*, no
matter whatever left to right or right to left associativity.

kind regards,

Jos

[weaknessforcats]

i= 42;
i+= i-= i*= i/= 1;

So this works just because the lvalue is different?

[code=c]
i+= b -= c*= d /= 1;
i = b = c = d = 5;
[/code]

K&R says the order of evaluation of operands is unspecified.

So should I be coding:
[code=c]
i += (b -= (c *= (d /= )));
i = (b = ( c = (d = 5)));
[/code]

I've never seen code like that.

I know that:
[code=c]
x = f() + g();
[/code]

is indeterminate if f() and g() alter a variable that they both depend on.

Help me out here.

[JosAH]

So this works just because the lvalue is different?

[code=c]
i+= b -= c*= d /= 1;
i = b = c = d = 5;
[/code]

K&R says the order of evaluation of operands is unspecified.

So should I be coding:
[code=c]
i += (b -= (c *= (d /= )));
i = (b = ( c = (d = 5)));
[/code]

I've never seen code like that.

I know that:
[code=c]
x = f() + g();
[/code]

is indeterminate if f() and g() alter a variable that they both depend on.

Help me out here.

The definition for undefined behaviour (sic) is quite simple: when a mutable lvalue
(e.g. a variable) is changed more than once before a sequence point is reached
(a semicolon) the behaviour (result) is undefined.

Your example above is fine because your altering different mutable lvalues only once.
Parentheses don't help: they alter the precedence or associativity only, e.g.a-b-c is
different from a-(b-c). The order in which the operands a, b, and c are evaluated is
unspecified indeed.

The original example where the mutable lvalue 'i' is altered twice causes undefined
behaviour according to the spec.

I don't have the Standard text available on this laptop (I left the other one at the office),
but remind me if you want me to email the text (it's the latest draft of the C99 Standard).

kind regards,

Jos

[weaknessforcats]

The definition for undefined behaviour (sic) is quite simple: when a mutable lvalue
(e.g. a variable) is changed more than once before a sequence point is reached
(a semicolon) the behaviour (result) is undefined.

I will try to keep this inthe forefornt of my mind.

Thank you for bearing with me.

BTW I would like to see the standard text. I assume in this area C99 and C++ 1998 are the same. Yes?

[JosAH]

I will try to keep this inthe forefornt of my mind.

Thank you for bearing with me.

BTW I would like to see the standard text. I assume in this area C99 and C++ 1998 are the same. Yes?

On our way to my brother and his wife we stopped by at the office; this is the
relevant paragraph from annex J.2. I wasn't a member of WG-J16 so I don't know
whether or not C++ simply duplicated this annex; I think not because I can
imagine certain situations in C++, non-existent in C, that also can cause undefined
behaviour.

Here's the paragraph:

       J.2  Undefined behavior

         -- Between two sequence points, an object is modified more
            than once, or  is  modified  and  the  prior  value  is
            accessed other than to determine the value to be stored
            (6.5).

And this is what paragraph 6.5 talks about:

       6.5  Expressions

       [#1]  An  expression is a sequence of operators and operands
       that specifies computation of a value, or that designates an
       object  or  a  function,  or that generates side effects, or
       that performs a combination thereof.

       [#2] Between the previous and next sequence point an  object
       shall  have  its  stored  value modified at most once by the
       evaluation of an expression.  Furthermore, the  prior  value
       shall  be  accessed  only  to  determine  the  value  to  be
       stored.60)                                                   *

       [#3]  The grouping of operators and operands is indicated by
       the syntax.61)  Except as specified later (for the function-
       call  (),  &&,  ||,  ?:,  and comma operators), the order of
       evaluation of subexpressions and the  order  in  which  side
       effects take place are both unspecified.

kind regards,

Jos

[weaknessforcats]

Thank you so much.

I am sorry to be so difficult about this, but I have had to adjust a core belief. From the section of the standard, I see completely what you have been talkling about.

I have been using C++ for 17 years and still I am plugging holes in my knowledge. This is one less hole.

[JosAH]

Thank you so much.

I am sorry to be so difficult about this, but I have had to adjust a core belief. From the section of the standard, I see completely what you have been talkling about.

I have been using C++ for 17 years and still I am plugging holes in my knowledge. This is one less hole.

No need to apologize; that Standard is lawyers' stuff; and it's needed now and
then. The days when K&R sloppy definitions ruled are over, C++ started off way
better than C did but still: those Standards are needed, That draft text has no
copyright at all; maybe I can post it in the C/C++ Articles section (it's quite large).
I have to check it out.

kind regards,

Jos