This question already exists:
Analysis of the operation order of logical operators [closed]
Closed 11 days ago.
What is the output result of the following formula
We have known
int a,b,c;
a = 3;
b = 4;
c = 5;
a||+c&&b-c;
After running the code, I get the answer as 1.
I know the order of operators, but it is difficult to use them.
But how to analyze the result, that is, what is the detailed operation?
I want to know how this+participates in the operation.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have been looking at some code that fills arrays with samples created using an IFFT (Inverse Fast Fourier Transform).
When the author iterates the array he uses an if construct that looks like this:
int idx;
for (idx = 1; idx < (tableLen >> 1); idx++) {
freqWaveRe[idx] = 1.0 / idx; // sawtooth spectrum
freqWaveRe[tableLen - idx] = -freqWaveRe[idx]; // mirror
}
Can you explain the terminating condition:
idx < (tableLen >> 1)
Why would you do something like this and what does it mean?
The bit shift operator used in this expression:
idx < (tableLen >> 1)
Terminates the for loop after iterating through the first half of the array. The right shift operator moves the value one bit to the right. Moving it one bit to the right divides it by two.
1010 in binary = 10
If we right shift it one bit we get:
0101 in binary = 5
A couple more things:
Tony D mentioned some comments made that this 'will not work well if idx is negative'. Negative numbers are represented differently. Sometimes negatives are stored with the first bit representing the sign. If you shift the sign right you will lose that information and cause a bit of a mess.
Tony D also said "it was historically an optimisation when bit-shifting opcodes executed faster than division, and optimisers couldn't be trusted"
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I'm studying C in school and I had this question, and I'm having trouble solving it.
What does the following code do?
#define N (100)
int main(void)
{
unsigned short i = 0;
unsigned long arr[2*N + 1];
unsigned long a = 0;
for (i = 0 ; i < N ; ++i) {
a ^= arr[i];
}
printf("%lu", a);
return 0;
}
It would be really helpful if you could explain it to me!
Thanks!
It's usually a good idea to explain what you understand, so we don't have to treat you as though you know nothing. Important note: This code behaves erratically. I'll discuss that later.
The exclusive or operator (^) produces its result by applying the following pattern to the binary representation of the numbers in question:
Where both operands (sides of the operator) contain different bits, the result will contain a 1 bit. For example, if the left hand side contains a right-most bit of 0 and the right hand side contains a right-most bit of 1, then the result will contain a right-most bit of 1.
Where both operands (sides of the operator) contain the same bit, the result will contain a 0.
So as an example, the operands of 15 ^ 1 have the following binary notation:
1111 ^
0001
... and the result of this exclusive or operation will be:
1110
Converted back to decimal, that's 14. Xor it with 1 again and you'll end up back at 15 (which is the property the silly xor swap takes advantage of).
The array[index] operator obtains the element within array at the position indicated by index.
The ^= operator is a compound operator. It combines the exclusive or and assignment operators. a ^= arr[i]; is roughly equivalent to a = a ^ arr[i];. That means: Calculate the exclusive or of a and arr[i], and assign it back into a.
for (i = 0 ; i < N ; ++i) /*
* XXX: Insert statement or block of code
*/
This denotes a loop, which will start by assigning the value 0 to i, will repeatedly execute the statement or block of code while i is less than N (100), incrementing i each time.
In summary, this code produces the exclusive or of the first 100 elements of the array arr. This is a form of crude checksum algorithm; the idea is to take a group of values and reduce them to a single value so that you can perform some form of integrity check on them later on, perhaps after they've been trasmited via the internet or an unreliable filesystem.
However, this code invokes undefined behaviour because it uses unspecified values. In order to avoid erratic behaviour such as unpredictable values or segfaults (or worse yet, situations like the heartbleed OpenSSL vulnerability) you need to make sure you give your variables values before you try to use those values.
The following declaration would explicitly initialise the first element to 42, and implicitly initialise all of the others to 0:
unsigned long arr[2*N + 1] = { 42 };
It is important to realise that the initialisation part of the declaration = { ... } is necessary if you want any elements not explicitly initialised to be zeroed.
this function will print unpredictable value.
because of unsigned long arr[2*N + 1]; arr is not initialized and it will have random content based on data on you memory.
a ^= arr[i]; is equal to a = a^arr[i]; so it will do this for multiple times (because of loop) and then it will print it.
This question already has answers here:
Why does the expression a = a + b - ( b = a ) give a sequence point warning in c++?
(4 answers)
Closed 7 years ago.
To swap to integers, A and B, this seems to work in C,
A = A + B - ( B = A);
Why does this work?
And if this works in all conditions, can this be used to shorten any other commonly implemented algorithms?
Actually it invokes undefined behaviour according to standards-
C99 §6.5: “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 read only to determine the value to be stored.”
You should not rely on code like that to work because it relies on the fact that it is processed from left to right.
Any implementation that does not do it like that is going to make it fail.
You should avoid writing code that does not work in all cases on all platforms and is not compiler independent, or relies on things that are not documented nor well defined.
So why does it work if you go from left to right :
Suppose A = 1 and B = 3
A = A + B - ( B = A);
A = 1 + 3 - (1) = 3
The assignment of B happens where i left the ()
Bottom line is that only when processing left to right , the assignment of B to A is happening later.
When processing right to left same example :
A = A + B - ( B = A);
A = 1 + 1 - (1) = 1
Now the assignment of B is happening first.
Again, you should not rely on code that is not clear for the reader what is happening, and which is compiler dependent which this is the case here.
This is only "shorter" than the standard/obvious way to do it, in the number of lines/semicolons used.
It introduces additional operations which might disallow optimization by the compiler
It worsens readability (as mentioned by D.R.)
It (ab)uses non-standard behavior (as mentioned by Marion), which might make it fail with some compilers
You should never use it.
This question already has answers here:
Is x += 1 more efficient than x = x + 1?
(6 answers)
Incrementing: x++ vs x += 1
(5 answers)
Why is i=i+1 faster than i++?
(5 answers)
Closed 8 years ago.
Is there is any difference between these two statements performance wise ?
i++;
i = i + 1;
Depends on the optimisation. i++ can, on most processors, be represented as a single machine language instruction. i = i + 1, on the other hand, could be represented by up to four: load i, load 1, add, store to i; although, even a middling smart compiler should be able to recognise it can rewrite it into the former.
no, there is no difference. The compiler will compile these into the same assembly
This question already has answers here:
Why are these constructs using pre and post-increment undefined behavior?
(14 answers)
Closed 8 years ago.
Kindly explain the output for the following code:
#include<stdio.h>
#include<stdlib.h>
#define SQUARE(x) (x*x*x)
int main() {
int x = 3;
int y = SQUARE(++x)/x++; // Undefined behavior even though it doesn't look
// like it here
printf("%d %d",x,y);
return 0;
}
Output: 7 25
Please explain how the value of y comes to be 25?
The macro is misnamed, but that's just a red herring. The two statements expand to:
int x = 3;
int y = (++x * ++x * ++x) / x++;
This is undefined behavior, since x is being modified more than once between sequence points. The compiler is allowed to do almost anything; it can interleave the uses of x and the pre- and post-increments of x almost anyway it wants. It can do things left-to-right, in which case, you get:
int y = (4 * 5 * 6) / 6;
Under this scheme, x is now 7 and y is now 20.
It could have done things right-to-left:
int y = (7 * 6 * 5) / 3;
Now, y is 70.
It could have cached the value of x at almost any point and used it. Try running your program under various compilers, with various optimization levels. Does gcc -O4 differ from cc? In fact, quoting the Internet Jargon file:
nasal demons: n.
Recognized shorthand on the Usenet group comp.std.c for any unexpected behavior of a C compiler on encountering an undefined construct. During a discussion on that group in early 1992, a regular remarked “When the compiler encounters [a given undefined construct] it is legal for it to make demons fly out of your nose” (the implication is that the compiler may choose any arbitrarily bizarre way to interpret the code without violating the ANSI C standard). Someone else followed up with a reference to “nasal demons”, which quickly became established. The original post is web-accessible at http://groups.google.com/groups?hl=en&selm=10195%40ksr.com.
So, I'd be a lot more careful here. Do you want demons flying out of your nose?