Maximum PC

While doing a quick C# review / cram, I've come across some interesting code examples that have surprised me. However, I would have bet BIG money that I would have gotten the following output right. See if you can guess the output _before_ running this code... and if anyone can provide a lucid explanation of what is happening under the covers, I'd appreciate hearing it. (Maybe this is one of the reasons why I like functional programming so much!)

I was able to determine the output correct without running (verified it with equivalent C++ code). The difference between prefix (++a) and postfix (a++) is that postfix operators increment the value after the line has ran, while prefix operators increment their values before the line is ran.



Based on the above, the assembly for prefix and postfix operations probably look something like this:

I have a doubt ..What is the output for the following statement?????

x=k++ + ++k;

According to Wikipedia (because I was rusty on the rules), what you posted can be considered an "undefined" operation, as quoted:

You can read about it at https://en.wikipedia.org/wiki/Increment ... _operators

However, from what I do know about postfix/prefix unary operators, postfix is the very last thing to do, prefix is the very first thing to do. So:



Remember, computers are literal genies. If you don't know what the above will do right away, then don't do it. It may be more lines of code, it may add another assembly line, but if you want something to be done clearly as you intend, break it down into atomic steps. So if I wanted to increment k, then make x = k + k, then increment k again:



It's very clear what I'm doing.

According to this Wikipedia article, the prefix and postfix operators are defined in the order of operations for c/c++. So, x = k++ + ++k is defined.

An interesting example:

When I run it, I get c = 33, but from what I know, I think c should be 37, and I don't see how it could be 33.

I agree with you LatiosXT, in practice code should not be this complicated to read.

Except this is C#/Java, so it may be different. But it may not, since they both derive from C anyway. Either way.


You increment c first, this makes c = 14. So it's 19 + 14 = 33.

Considering this, you should NEVER use an increment/decrement operator in a mathematical operation. It's more so you don't have to write c +=/-= 1.

http://msdn.microsoft.com/en-us/library/aa691323%28v=vs.71%29.aspx


For some reason I was thinking (c+5) would make c=18, then ++c would make c=19, so 18+19=37. Brain fart.
But wouldn't the parenthesis precede the prefix operator, so it'd be 18+14=32? Replacing "(c+5)" with an "addFive(int)" function does return 32.

Aha, see, this is the undefined part then.

If we went by that table Wikepedia posted, then it would make sense that the order of operations is strictly the order that appears in the list. So the increment/decrement operators really have precedence over parenthesis.

If we went with order of operations like in math (such as PEMDAS), then we would have to evaluate (c+5) first, because we encountered that first and it's on the same precedence level as increment/decrement. But your compiler didn't do that.

EDIT: Actually I saw that Wiki listed suffix increment/decrement in the same precedence level as parenthesis, and prefix is after. So yes, (c+5) should've gone first. But still it didn't.

Either way, this seems to prove that an arithmetic operator next to an increment/decrement operator is undefined.

EDIT 2: If the operation were "(c+5) + c++", you get 32. And the parenthesis in the list is a function call... so I'm confused again

The parenthesis in that list actually refer to a function call. Parenthesis by themself actually don't appear in that list.

So according to Microsoft, my original knowledge of prefix/postfix operators was correct.


Buuuuut, again. Don't use increment/decrement operators in a math expression. That just confuses people.

Sorry about letting my thread dangle. I had to attend an out of state lawsuit and finish some data analysis for a university. Anyways, I have an answer for the third case that makes sense.


I don't believe that thinking in terms of "after the line is ran" is helpful since the line of code may contain other operations and/or multiple lines of code.

I think we all agree that the third case that is the only tricky case. In order to get at the root of the problem, I used the Java disassembler, javap, to disassemble the class file. Note that I moved each 'case' into a seperate method to make tracking the bytecode easier. My comments are inlined using ///.



As you can see from the bytecode, case1 and case3 are exactly the same except for line(?) #9. For the first case, the value 11 is placed into the memory reference by a, then the value 10 for b. In the third case, the value 11 is placed into b's memory reference THEN the value 10 is placed into b's memory reference! Pretty surprising... =)

How are you arriving at 37? I got 33 when I did this by hand and 32 when I ran it in Java.



This is how Java came up with a value of 32... another interesting result.

This ambiguity really makes me appreciate working in functional programming languages! =)

Below is Common Lisp code for how C and Java arrive at their various solutions. The world would be a much better place if C hadn't flourished under cheap Unix machines.

[/code]

Unless you're using a functional programming language, then it only makes PERFECT sense! =)

The ambiguity here really boils down to whether or not parenthesis are higher on the order of operations than prefix operations. It appears that in Java they are, but in C they are not.


Is this ambiguity due to a fundamental difference between functional and procedural/OO programming languages, or is it just the effect of a shortcut in Java and C/C++ causing extra complexity that may lead to unexpected results?

As fun as it is to learn such things, again I'm going to iterate that you shouldn't be using increment/decrement operators in an arithmetic operation. I mean, I would freak out if I saw c = ( c + 5 ) + (c = c + 1) in a normal math setting. How are you supposed to solve this?

Personally, I believe this illustrates one of the difference between funcational and imperative programming languages. Imperative languages require you to learn substantially more syntatic information, such as operator precedence, than is required in functional programming languages. Also, I wouldn't call either the prefix or postfix operators shortcuts. They're fundamentally the same as any of the other operators, right?

Take CL as an example, the language syntax is incredibly simple. The first term following an open paren is a function call. Any terms proceeding the next closing are arguments to the function. Function calls are evaluated in order from left to right. If a function call has an argument that is itself a function call, the inner function call is evaluated and used as an argument for the outer function call. There is some systatic sugar to make certain common tasks a bit easier, but the only language syntax that you must learn is (fn arg1 arg2 ...). That's it.

To be fair, you also need to know a bit more syntax in order to define a function, which is done using a macro that changes the syntax (but at this point we're comparing large portions of languages).
(defun fn-name (fn-arg1 fn-arg2 ...) (... function body ))

Now an astute student of computer science will notice that the examples from the proceeding post are not technically "pure" functional programming because I'm manipulating the state of a variable. This is true -- I set the variable c to a value and used the incf function to increment it. One of the design goals of Common Lisp was to be a practical programming language for industry developers, not just an interesting academic language like Scheme. Because of this broad goal, CL actually supports several programming styles including imperative, functional, applicative, object-oriented and meta-programming / macros. CL programs are often written in a bottom-up style. First, small functions and macros are written in an imperative style of programming using only local variables. These functions are then used to build up the program. At this higher-level, functional programming and/or object-oriented programming are often employed.

Agreed. We should start a thread on composing mathematical functions! =)


If someone had done this one of my teams, they would be flogged!

I actually got the answer right. Starting with c = 1 the answer is 8 (in Java). While I got the right answer, what I didn't think about are the two assignments that occurs due to the (c = c + 1) term. Fool me twice! The disassembled code looks pretty darn inefficient. Maybe I should look into doing some research on compiler algorithms.



The double assignment is a bit more obvious in CL... again, I think it is because of the simpler syntax and explicit use of parens.


Out of curiousity, I decided to take a look at the disassembled Lisp code. It is more efficient than the Java code requiring only 9 instructions (vs 13 for Java). I can't really explain why this is the case, especially given the number of man-hours that have gone into Java compiler development, but I will hypothesis that it may be due to the simpler parsing syntax of CL vs Java (ie a recursive descent parser vs a LR parser). I should also emphasize that just because the CL code requires fewer isntructions (and can be compiled directly to ML), it doesn't necessarilly mean that the CL code is faster than the Java code. The JVM might be performing further optimizations that eliminate some of the instructions.

It seems like it's a difference in cultures, because I don't think there's anything fundamental to imperative languages that makes them have to have substantially more syntax. At the very basic level, there are assignments, mathematical operations, and functions.

I'd agree, I'd say the prefix and postfix operators are syntactic sugar.

Perhaps not substantially more syntax, it is pretty hard to quantify this type of thing. As we discussed before, in an imperative programming language (IPL), you need to know the operators, which is a wash because you need to know the functions in a functional programming language (FPL), but the IPL also requires you to be familiar with the operator precedence rules. The real difference is that the grammar in an IPL is almost always larger. For example, why doesn't the following code compile?

This doesn't compile in Java, C/C++ or any other IPL (AFAIK), but using the if function in an assignment function is perfectly natural in a FPL. I can only use an if condition if it "starts a line", or more explicitly, whenever the grammar says it is OK to use an if condition. I also have to watch out for dangling if clauses and things of that nature (which aren't an issue with an FPL due to the order of function calls being explicitly defined by the user). This may seem like a fairly trivial example, but there have been plenty of occasions when I've been writing code in Java and thought "Lisp sure would have made that easier".

In most IPLs, elements of an array, list and string are accessed using different syntax. In Java, I access the first element of an array with foo[0], but the first element of a list is accessed using foo.get(0), and the first element of a string using charAt(), which returns a char instead of a string with a single element (This requires a substring() call). To find the length of an array, I access the public length member (ie foo.length). The length of a string requires a method call to length() while the list a call to size(). Accessing part of a list, array and string also require different methods (esp for an array). And frankly, Java is much easier to remember than C or C++ (especially when dealing with strings). In CL, these data types are all accessed using the same function calls w/o any variation in syntax.

Many IPLs utilize pointers which add another layer of syntax for how to allocate and free memory. Again, there is syntatic sugar for pointer assignments in C/C++. More syntax to memorize.

Typically, IPLs have a number of reserved and/or keywords. I believe Java has 34 keywords and a few reserved words. There are also usually a number of grammar rules concerning naming local variables, global variables and functions. Often this is due to how operators and variables or functions interact. In most IPLs, I can't name a variable a+b even though that may be a perfect description for the variable!


In C and C++, there is some interesting syntax related to global variables and variable scoping. The following code will probably test your memory pretty well. C++ also has the oh-so-fun macro system.


Another interesting area to contrast is function declarations. This probably the one place where the FPLs have more syntax than the IPLs, because they generally support more language features related to functions (eg parameter declaration, multiple return values, higher order functions, returning functions, etc), but the IPLs still manage to make things more difficult IMO. Take these C++ examples using default parameter values and multiple arguments.

For some reason, all parameters without default values must come before parameters with default values. Why? Who knows... just put it in the memory banks. Nope, you don't have to worry about that type of thing in CL. Occasionally you have to write a function that may take any number of arguments (eg the mean() and sum() functions in R). Fine, I just use an ellipsis, right? Well, you need to be able to access those args in the function. How? The <cstdarg> macro to the rescue. That macro is more fun than a migraine... let me tell you.

Several IPLs support operator overloading, which can be convenient, but you must learn additional syntax/grammar rules. Do you know which of the 42 operators can be overloaded in C++. Do you know the three operators that cannot be overloaded? Did you know there were 45 operators?!

In the case of C and C++, you also have header files and the macro system to contend with as well.


Sure, they are syntactic sugar. However, languages include syntactic sugar because it is something that is done frequently. If anything, you should probably especially familiar with the syntactic sugar in a language because you're going to see it being used all the time. If you actually wrote "int n = n + 1;", you're boss is going to think something is wrong with you! =)