This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
C++ Comma Operator
About a year ago I noted some obscure syntax in a coding project I was working on:
table_value = table_index += 2, valueFromTable(table_index);
Does anyone recognise this?, it's like an assignment with an additional statement. This compiled in our entire suite of cross-platform compilers, so I'm pretty certain its valid C++ but I've never seen anything like it.
Any insight would be appreciated.
Gearoid
EDIT: heres some working code:
#include <iostream>
using namespace std ;
int valueFromTable(int a) { return a ; }
int main()
{
int table_index = 0 ;
int table_value = table_index += 2, valueFromTable(12);
cout<<table_value<<endl;
return 0 ;
}
This is the Comma operator.
It's standard C and C++ but heavily frowned upon.
It evaluates both arguments, and returns the result of the second.
Related
This question already has answers here:
Macro Expansion
(7 answers)
The need for parentheses in macros in C [duplicate]
(8 answers)
Closed 4 years ago.
#include <iostream>
using namespace std;
#define squareOf(x) x*x
int main() {
// your code goes here
int x;
cout<<squareOf(x+4);
return 0;
}
I thought the answer would come as 16 but it came out as 4.
I am confused how does this works.
16 would never be the result here. Let's say you would have initialized x with 0, then you would have your x+4 replaced by x+4*x+4 which would evaluate as 0+4*0+4 = 4.
Preprocessor macros replace source code, they are not functions.
You might now think that maybe
#define squareOf(x) (x)*(x)
would be better, but consider that then
int x = 2;
int y = squareOf(x++);
would result in y = (2)*(3) = 6, not in 4.
If you do not have a really good reason, avoid preprocessor macros. There are good reasons, but if something behaves like a function, better make it a function.
Now take a look at this:
template <class T>
inline T squareOf(const T& number)
{
return number*number;
}
As inline, it does also replace code (at least if the compiler wants so), but here, this one actually behaves like a function (since it is one). Wouldn't expect a bad outcome from that one.
This question already has answers here:
Using the equality operator == to compare two strings for equality in C [duplicate]
(9 answers)
Closed 4 years ago.
Whenever I run this in the compiler I get 1 returned to me. However, I've been told that this shouldn't return 1 and that my compiler is wrong and can't be trusted.
Is my friend right in that the compiler's I use are giving me the incorrect answer, or is this supposed to return 1?
#include <iostream>
#include <string>
int main()
{
bool lol = "abc" < "abcd";
std::cout << lol;
return 0;
}
The code has Undefined Behaviour, because it's using an oredering comparison operator on two pointers (the address of the string literal "abc" and that of the string literal "abcd") which are not part of the same array. It can therefore do absolutely anything.
This question already has answers here:
Undefined behavior and sequence points
(5 answers)
Closed 7 years ago.
During study in C++ at school, when we learn about operator ++ in C++, we know ++c and c++ are different.
When we test more about this with this kind of code:
#include <iostream>
using namespace std;
int main(){
int c=10;
cout<<++c<<" "<<c++<<endl;
return 0;
}
Why did above code gave output of 12 and 10 in C++?
The computer (we tests with both cout and printf, we also tried VC++ and g++) give this to me:
12 10
Both "cout" and "printf" gave the same result.
But when we test in calculation, the result is all right.
#include <iostream>
using namespace std;
int main(){
int c=10;
int r=++c^c++;
cout<<r<<endl;
return 0;
}
Above source code gave me 0 which means while above XOR operation executing, both left hand side (++c) and right hand side (c++) giving the same value to XOR operator which is 11 (We get the value 11 by replacing c++ with 11 and computer gives the same result 0).
This is really wired. Did anyone noticed this?
By the way, we test in both debug mode and release mode in both Windows and Lubuntu. So we think this is relating to the standard library. But we aren't expecting that we can read the stdlib as a NOOB. So hoping someone can find a reason or solution.
The code int r=++c^c++; is undefined behaviour and should not be used, not ever. You can't modify the variable twice before sequence point.
This question already has answers here:
Undefined behavior and sequence points
(5 answers)
Closed 7 years ago.
I got stuck in operator precedence problem...In the first look it looks quite easy but it is really hard ...and i run it on DEV as well as Visual studio but it gives different output and i m completely shocked .here is my code
#include<iostream>
using namespace std;
int main(){
int a=0;
a=++a*++a*a++;
cout<<a<<endl;
}
it gives 8 output in Dev and g++ but 9 in Microsoft Visual studio 2013, any help would be appreciated ...Also plz tell me in which order does these operators call each other so that to get the desired output on the console.
a=++a*++a*a++;
Should be
++a;++a; //a = 2, because you have the two pre-increments.
temp = a * a; //temp = 4
temp = temp * a; //temp = 8
a = temp; //a = 8
a++; //a = 9, for the post-increment.
So you should probably report this to the compiler teams along with your CPU specs.
However, according to gnu.org regarding operator precedence:
In C you cannot assume that multiple subexpressions are evaluated in
the order that seems natural. For instance, consider the expression
++a * f(). Does this increment a before or after calling the function f? The compiler could do it in either order, so you cannot make
assumptions.
(Note that the above is taken from the GNU c manual).
So technically this is not a bug, even though it's inconsistent.
Short term solution:
a = 9;
f you really wrote code like this, you are in trouble.
Better you must to use aux variables like
#include<iostream>
using namespace std;
int main(){
int a=0;
int aux = ++a;
a=aux*aux*a++;
cout<<a<<endl;
}
or something like this to solve the ambiguity.
If you question is for learning purposes, there are cases that has no an unique result, because is the way that the compiler solve this equation.
Dr.dobbs's Magazine show several cases like this, and all equations haven't an exact result.
I can't get now some page to show code you never will use, to avoid bugs like this.
Just for example: http://www.cplusplus.com/forum/beginner/26383/
This is a sequence-point issue, and should have warned you about it if you have -Wsequence-point enabled. In essence your statement is undefined, and is why different compilers give different results.
Please look at a previous answer to this problem: undefined-behavior-and-sequence-points
This question already has answers here:
Undefined behavior and sequence points
(5 answers)
Closed 7 years ago.
I have here an equation i can't understand how c++ process this. Can someone explain this operation?
code:
#include <stdio.h>
main(){
int a[10] = {0,1,2,3,4,5,6,7,8,9};
int i = 0;
int num = a[i+++a[++i]]+a[++i+i++];
printf("\nnum1: %d i: %d,num,i);
}
why is the answer num = 9 while index i is just equal to 4;
Using ++ twice in the same expression on the same variable is explicitly undefined by all versions of both the C and C++ standards, and so i does not necessarily equal 4. It could be anything at the whim of the compiler writer.
Never do this. Never use ++ and -- twice in the same expression. There is no way to make any statement about what the resultant value will be, and no experience with what it does with one compiler will mean anything with respect to what another compiler does.