I have overloaded both & and *. If I do this:
hgh=(xxx&yy)*vprod1;
It works as expected.
If I do this:
hgh=xxx&yy*vprod1;
I get a compiler error Invalid operands to binary expression.
How does the compiler read this: hgh=xxx&yy*vprod1; -- Wouldn't it move from left to right, just as in the above example, with parenthesis? If the parenthesis were located in a different part of the expression, I can understand how there could be differences in how the compiler read it, but why would that apply here?
It should be worth noting that the return value of both overloads is identical, and returns the same type as xx and yy are in this calculation.
* has higher precedence than &, so it's applied first. Your expression is basically xxx & (yy * vprod1);
Related
In the for loop at initialization part you can declare and initialize many variables as you like but ofcourse they have to be same type.In conditional part you can apply any expressional statements like AND(&&),OR(||),>,<,== etc.
but(,) is not a expression .How it works here
just a=1,2,3,4,5,6 and b=1,2,3,4,5,6,7,8,9,10
and a<6,b<9 returns a=1,2,3,4,5,6,7,8,9=b
for(int a=1,b=1,c=2,d=5;a<4,b<10;a++,b++)//initialize variables and using , between expression
{
cout<<a<<" "<<b<<endl;
}
Because...that's not really how things work at all.
The comma operator evaluates and discards its left operand (so in most cases its left operand will have side effects). After the left operand is evaluated (and any side effects from it have happened), the right operand is evaluate. The value yielded from this is the value of the right operand.
Actually it's not or, the behavior of comma operator can be described as:
In the C and C++ programming languages, the comma operator
(represented by the token ,) is a binary operator that evaluates its
first operand and discards the result, and then evaluates the second
operand and returns this value (and type).
From wiki: https://en.wikipedia.org/wiki/Comma_operator
So only the result of k<10 taken into the account.
If I have a user-defined operator+() as in:
class A
{
public:
A operator+(A)
{
return A();
}
};
Then the following works as expected:
A a = A() + A();
but g++-4.7 gives an error message on the following:
A a = (A()) + A();
The error message in particular is error: no match for ‘operator+’ in ‘+A()’.
It looks like the (A()) is being ignored in the expression.
My question is: is A a = (A()) + A(); supposed to compile and if not, why not?
Note: this happened to me when I did #define X (Identity()) and then tried doing X + X.
It's a cast syntax.
The reason for that is that casting and the unary addition, subtraction and multiplication (the dereference operator) have higher precedence than their binary counterparts. Since the white spaces here don't matter this can also be read as:
A a = (A()) +A();
The cast and unary+ have higher precedence than the binary operator+ so the expression takes the former meaning.
You might be wondering (as I did) how you can cast when the thing inside is not a type. Enter THE MOST VEXING PARSE!, which means I am trying to cast an object of type +A() to a function taking 0 arguments and returning an object of type A.
For the record, the syntax:
A a = ((A())) + A();
gives what you want since the double brackets can't be a cast and we're back to parsing the binary operator+ expression.
This also explains why the problem doesn't occur with the division operator instead of the addition, it doesn't have a unary counterpart.
Is it standard-conforming to use expressions like
int i = 1;
+-+-+i;
and how the sign of i variable is determined?
Yes it is. Unary + and - associate right-to-left, so the expression is parsed as
+(-(+(-(+i))));
Which results in 1.
Note that these can be overloaded, so for a user-defined type the answer may differ.
Your operators has no side effect, +i do nothing with int itself and you do not use the temporary generated value but remove + that do nothing and you have -(-i) witch is equal to i itself.(removing + in the code will convert the operator, I mean remove it in computation because it has no effect)
i isn't modified (C: without intervening sequence points|C++: in an unsequenced manner) so it's legal. You're just creating a new temporary with each operator.
The unary + doesn't even do anything, so all you have is two negations which just give 1 for that expression. The variable i itself is never changed.
So i'm programming a cmd-based calculator in C++. I finished it, but i was wondering, after converting the infix to postfix, i have a queue called the postfix queue containing the operators/operands in correct order. How do I convert a postfix expression back to infix?
If you don't mind producing some extra parentheses, it should be pretty easy. You basically "evaluate" the postfix data about like usual, except that when you get to an operator, instead of evaluating that operator and pushing the result on the stack, you print out an open-paren, the first operand, the operator, the second operand, and finally a close-paren.
If you didn't mind changing the order, it would also be pretty easy to avoid the extraneous parentheses. Walk the expression backwards, rearranging things from operator operand operand into operand operator operand. If you encounter an operator where you need an operand, you have a sub-expression to print out similarly. You need to enclose that sub-expression in parentheses if and only if its operator is of lower precedence than the operator you encountered previously.
For example, consider: a b + c *. Walking this backwards, we get *, then c, so we start by printing out c *. Then we need another operand, but we have a +, so we have a sub-expression. Since + is lower precedence than *, we need to enclose that sub-expression in parentheses, so we get c * (b + a).
Conversely, if we had: a b * c +, we'd start similarly, producing c +, but then since * is higher precedence that +, we can/could print out the a * b (or b * a) without parens.
Note that with - or / (or anything else that isn't commutative) you'd have to be a bit more careful about getting the order of operands correct. Even so, you're not going to get the original expression back, only an expression that should be logically equivalent to it.
I know this is silly question but I don't know which step I'm missing to count so can't understand why the output is that of this code.
int i=2;
int c;
c = 2 * - ++ i << 1;
cout<< c;
I have trouble to understanding this line in this code:
c = 2 * - ++ i <<1;
I'm getting result -12. But I'm unable to get it how is precedence of operator is working here?
Have a look at the C++ Operator Precedence table.
The ++i is being evaluated, yielding 3.
The unary - is being evaluated, yielding -3.
The multiplication is being done1, yielding -6.
The bit shift is evaluated (shifting left by 1 is effectively multiplying by two) yielding -12.
The result -12 is being assigned to the variable c.
If you used parentheses to see what operator precedence was doing, you'd get
c = ((2 * (-(++i))) << 1);
Plus that expression is a bit misleading due to the weird spacing between operators. It would be better to write it c = 2 * -++i << 1;
1 Note that this is not the unary *, which dereferences a pointer. This is the multiplication operator, which is a binary operator.
Operator precedence defined the grouping between the operators and their operands. In your example the grouping is as follows
c = ((2 * (-(++i))) << 1);
That's how "precedence of operator is working here" and that's the only thing it does.
The result of this expression is -6 shifted one bit to the left. This happens to be -12 on your platform.
According to your comment in another answer, you mistakenly believe that operator precedence somehow controls what is executed "first" and what is executed "next". This is totally incorrect. Operator precedence has absolutely nothing to do with the order of execution. The only thing operator precedence does, once again, is define the grouping between the operators and their operands. No more, no less.
The order of execution is a totally different thing entirely independent from operator precedence. In fact, C++ language does not define any "order of execution" for expressions containing no sequence points inside (the above one included).