Eric Lippert talks about some choices that were made in creating C#. He emphasizes repeatedly that C# is not “C++ with the X parts taken out” – where X might be “stupid” or “complicated” or “reserved for smart people” depending on who you talk to. And I agree with him. C# is its own language with its own strengths. It enjoys a big advantage, too: it came from a blank page and wasn’t constrained by an existing code base. For example, one subtle source of bugs in C++ applications is that the order of subexpression evaluation is not enforced by a standard. If I write x=f(y) + g(z); it’s possible that one compiler (or one version of a compiler) might evaluate g(z) first, while another evaluates f(y) first. If these functions have side effects, this matters. I’ve always advised developers that if your functions have side effects, and you care what order they go in, split these expressions up into lines that happen in the order you want: x1= f(y); x2 = g(z); x = x1+ x2; for example.

Eric asks, “is there any benefit to the user of having this order of operations be unknown?” and of course there is not. The reason the order is unspecified in C++ is because there were compilers (from more than one vendor) before there was a standard. That’s not a constraint the C# team faced, so they laid down the law – subexpressions are evaluated from left to right. [Yes, I know some people claim it is a benefit to the user that the compiler is free to optimize by adjusting the order of evaluation. I just fail to see an optimization available by doing things in a different order.]

Two morals of this story. First, new languages can do some things older ones can’t, and that’s a good thing about those languages. Second, you really need to know how your language works, or some day it’s going to bite you.

Kate