|
after all that dumbing it down, I'm thrown for a loop (pun intended).
After reading a little bit more in the book they decide to give me a little exercise.
int x = 10;
int y = 100;
int z = y;
y = y++ + x;
z = ++z + x;
I thought I would do this in my head before writing it to the console window.
The first expression, the answer I got my head was:
110
(which turned out to be right, woo hoo)
The second expression I got wrong, in my head I came up with:
121
the console window printed out:
111
Console.WriteLine(y);
Console.WriteLine(z);
just before this exercise, the book showed me a table trying to explain:
primary, urnary, binary
<a href="http://www.widmarkrob.com">My Coding Journey</a>
|
|
|
|
|
WidmarkRob wrote: int z = y; Ok, what happens here is not "make x an other word for y", which is what I think you might have thought. It really means "let x have the value that y now has".
y later changed, z did not.
Ok z did change, but the assignment to y did not affect it.
WidmarkRob wrote: y = y++ + x; does not affect z, only y.
|
|
|
|
|
Try an experiment.
When you see a statement involving prefix or postfix increments, mentally (or even physically) re-write it to be several statements, moving the increment outside all other statements.
y = y++ + x;
Becomes:
int y2 = y;
y = y + 1;
y = y2 + x; In other words, the postfix increment of y is irrelevant, because the value is immediately discarded, and y is set to the value of the sum of the original value of y and x
z = ++z + x; Becomes:
z = z + 1;
z = z + x; That is all the compiler is doing - a prefix or suffix increment just gets done when it is met, that's all - it's syntactic sugar for the broken down statements above.
Having said that, try not to use them in "complex" statements: What happens may not be what you expect - different compilers interpret "when to do this" slightly differently, and that gave have a dramatic effect. Normally, pre-and post- increments are kept to simple things like array accesses and for loops.
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
OriginalGriff wrote: different compilers interpret "when to do this" slightly differently Not in C#. Or if they do, it's a compiler bug. There is only one right order of side-effects in C#, which is left-to-right.
|
|
|
|
|
I originally did add something to that effect, but deleted it because I didn't want to confuse the OP too much. Anyone who starts writing code like
int y = 10;
y = y++ + ++y*y--; deserves the headache they are going to get1.
1 When I find out and hit them.
154, by the way.
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
Ok, but IMHO you could now be confusing the OP with the possibility that there's some sort of quantum-magic involved that makes the result depend on the phase of the moon or something..
|
|
|
|
|
Do you want to sit there and work out why y++ + ++y * y-- equals 154? Quantum magic works for me!
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
Easy, 10 + 12 * 12. The complex cases don't really matter of course, I'm sure we're in agreement there - I just brought them into this to prove to OP that it really works that way.
|
|
|
|
|
I know - but it's not that obvious when you look at it, particularly if you come from a C / C++ background where a different result is a strong possibility. DevC++ will give you 132 for example.
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
Also fun: different version of GCC give different results (usually 132 or 142).
|
|
|
|
|
Now you see why I hit people who do it!
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
.. And if they turn the other cheek, hit them again This has got to be close to using GoTo statments or possibly worse....
|
|
|
|
|
I think of it as "Codefuscating"
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
To you or the compiler or perhaps both?
|
|
|
|
|
Oh just me, the compiler knows what it's doing. I just guess.
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
Quote: I just guess. debug.
FTFY
|
|
|
|
|
Worse. With goto at least only one thing can happen, even if it's not always immediately clear what that thing is.
|
|
|
|
|
I have seen some pretty nasty goto's in my life, but I have to agree that this seems to take the cake. Why would anybody want to use such a feature anyway, it seems daft.
|
|
|
|
|
I see you guys have been busy bees about this… I had to take a break, steam was coming from my ears because of this.
Anyway, I looked over the example in the exercise they gave me.
Give me about 30 min., I'll explain to you guys but I ended up getting the second expression in my exercise wrong.
By the way, thank you for trying to help clear this up for me.
Rob
<a href="http://www.widmarkrob.com">My Coding Journey</a>
|
|
|
|
|
Hi,
Sometimes a simple description can be very hard to grasp - especially if the simple description tries to abstract the details away.
In such cases I find it rewarding simply to dig a bit deeper...
Here goes the details:
.entrypoint
.maxstack 3
.locals init ([0] int32 x,
[1] int32 y,
[2] int32 z)
IL_0000: nop
IL_0001: ldc.i4.s 10
IL_0003: stloc.0
IL_0004: ldc.i4.s 100
IL_0006: stloc.1
IL_0007: ldloc.1
IL_0008: dup
IL_0009: ldc.i4.1
IL_000a: sub
IL_000b: stloc.1
IL_000c: ldloc.0
IL_000d: add
IL_000e: stloc.2
If instruction, stack and arithmic unit are alien terms to you, then above might be a bit tough. It is a window into a lower layer of code. The C# compiler outputs this in binary form as your assembly/executable. IL means Intermediate Language and it can be executed by a Virtual Machine aka a program. The idea is to simulate the arithmic unit of a cpu, so above code is also a window into history.
-- and ++ are special language features that comes nearly for free because of the (virtual) machine architecture.
I produced above from your code example by running IL Disassembly from Microsft .Net.
Kind Regards,
Keld Ølykke
|
|
|
|
|
Okay, just to recap… I'm going to show the example they gave me first… Then tell you how I understand what you guys have been trying to help me with.
Then I will post my exercise towards the end and try to explain how I came up with my answer doing it in my head before running the program and printing it to the console window.
<pre lang="c#">
// Example 3-2.cs
// Increment and Decrement
using System;
class ArithmeticOperators
{
public static void Main()
{
int x = 10;
int y = 100;
int z = y-- + x;
Console.WriteLine(z); // result = 110
Console.WriteLine(y); // result = 99 — The value of y after
// decrementing
z = --z + x;
Console.WriteLine(z); // result = 119
}
}
</pre>
So, we print out the variable z… Like it says, the result is 110. Okay, easy enough.
Just in my mind, the variable y automagically becomes 99.
Anyway, you guys have explained to me that the variable y takes on the new value after evaluating the expression.
Semi-sort of easy enough.
Using this as somewhat of a template for my exercise is probably what threw me off.
In the exercise, I got the first expression done in my head correctly. Meaning it matched what the console window printed out.
The second expression, using the example above.
I also thought the variable y would become the new value after evaluating the first expression.
That's why in my head, I came up with 121… The console window printed out 111.
Drill 3-1
Start with the following assignments:
int x = 10;
int y = 100;
int z = y;
Then write a C# program to compute and display the values of the
variables y and z after executing these expressions:
y = y++ + x;
z = ++z + x;
<a href="http://www.widmarkrob.com">My Online Journey</a>
|
|
|
|
|
WidmarkRob wrote: int z = y-- + x;
WidmarkRob wrote: Anyway, you guys have explained to me that the variable y takes on the new value after evaluating the expression.
y takes on the new value of y , which is sort of tautological..
One is subtracted from y , that is all.
|
|
|
|
|
Yes, I get that now…
Post-fix decrementing…
It takes on the new value after evaluating the expression.
On to my new problem.
I used this same type of thinking with my so-called simple exercise I was given.
y = y++ + x;
z = ++z + x;
In using that same thought process of y taking on the new value after evaluating the expression, in this new problem (the first expression).
I did this in my head before printing it to the console window and came up with 121.
The console window printed 111.
In trying to keep things in semi-sort of uniform fashion.
In my head, I also thought this variable y would take on the new value as well.
Where did I go wrong in my head?
<a href="http://www.widmarkrob.com">My Coding Journey</a>
|
|
|
|
|
|
int x = 10;
int y = 100;
int z = y;
Then write a C# program to compute and display the values of the
variables y and z after executing these expressions:
y = y++ + x;
z = ++z + x;
This exercise is virtually the same as the example they gave to me in the beginning. (My original question I was asking about)
When I print the variable y to the console window, the result is 110. (Which is what I came up but in my head)
Using the same thought process as in the example, where this variable y also takes on the new value (110)…
I used this new value in my head.
This so-called simple exercise is using "Boxing"? (Just throwing in another term that I learned, hopefully using it correctly)
the variable z now equals the variable y. (Which in my mind, I thought would equal 110)
The second expression.
Prefixes incrementing.
So I thought, 110+1+10.
That's how I came up with 121 in my head.
When I went to go print the variable z to the console window, the result was 111.
<a href="http://www.widmarkrob.com">My Coding Journey</a>
|
|
|
|