x+=x++;

Today I was looking through an internal C# user group list. One of the messages was about “x+=x++;” and what should be the right behavior. I thought this is more generally interesting, so I decided to blog it. But first, DO NOT WRITE THAT CODE!!!

Ok, with that out of the way, we can start…

Let’s take this code as an example:

int x = 3;

x += x++;

The first thing the compiler does whenever it sees something like z += y is to convert it to z = z + y. This is obviously true for +=, -=, *=, and /=. Ok, this was easy. Now we have just to consider:

x= x + x++;

This, by the way, gives the same result as:

x = x + x;

This, by the way, gives a different result from:

x = x++ + x;

This, by the way gives the same result as:

x = x + ++x;

As maddening as this may seem, it actually makes sense (once you understand how it works). But first, what is the difference between x++ and ++x? x++ returns the value of x to the current expression and then increments x. ++x increments x and then return its value to the current expression. Given this factoid (and knowing that c# evaluates expressions left to right), we can then consider what happens in the following case:

int x = 3;

x = x + x++;

Here is how the compiler conceptually evaluates it:

  1. x = (x) + x++ -> the first x gets evaluated and returns 3, x = 3
  2. x = 3 + (x)++ -> x gets evaluated and returns 3, x = 3
  3. x = 3 + (x++) -> x++ gets evaluated and x is incremented (to 4), x = 4
  4. x = (3 + 3) -> 3 + 3 gets evaluated and returns 6, x = 4
  5. (x = 6) -> x is assigned to 6 (overriding the previous value of 4)

Now let’s see how this one works:

int x = 3;

x = x++ + x;

  1. x = (x)++ + x -> x gets evaluated and returns 3, x =3
  2. x = (x++) + x -> x++ gets evaluated and x is incremented, x=4
  3. x = 3 + (x) -> x gets evaluated and returns 4, x = 4
  4. x = 3 + 4 -> 3+4 gets evaluated and returns 7, x = 4
  5. (x=7) -> x is assigned to 7 (overriding the previous value of 4)

Now let’s get to this one:

int x = 3;

x = x + ++x;

  1. x = (x) + ++x -> x gets evaluated and returns 3, x=3
  2. x = 3 + (++x) -> ++x gets evaluated and x is incremented, x=4
  3. x = 3 + (x) -> x gets evaluated and returns 4, x=4
  4. x = 3 + 4 -> 3+4 gets evaluated and returns 7, x = 4
  5. (x=7) -> x is assigned to 7 (overriding the previous value of 4)

I hope this is clear. By the way, in c++ the behavior for this expression is undefined…

But now… why did we make this legal? Why not err or warn at compilation time? Well…

  • We were wrong, we should have erred or warned, but now it is too late because if we change this we break code OR
  • It is quite complex to form a set of guidelines that the compiler can evaluate to be able to err just in the bizarre cases OR
  • We prefer to spend our time working on things people really care about instead of these corner-corner-corner cases

Does it matter which of the previous options is the correct one? Not really because…

YOU ARE NOT GOING TO WRITE THAT CODE J

Advertisements

Homeowner association transcripts…

Does anyone know if the homeowner association president for a condominium complex is legally forced to give the transcripts of their meetings to prospective buyers?

It is quite funny, the lady in charge just doesn’t want to talk to me. I know, I know, I shouldn’t buy that condo then… love over reason…

How much object relational framework do you really need?

It is always interesting for me to look at debates about object relational layers. I propose we define different levels of object relational support:



  1. No support: all the objects are persisted and queried by writing ADO.NET code by hand

  2. Code generation: you run a tool on your database (or on an abstract description of your schema) and the tool generates a bunch of objects for your tables and some ADO.NET code to retrieve/persist their state


    1. Total code gen: the tool generates all the ADO.NET code

    2. Partial code gen: the tool generates just code to intercept property accessors and provide delay loading, but all the data access code is in a separate compiled component

  3. Metadata based: no code generation phase. The access to fields and property goes through reflection and the data access code is not exposed in the user code


    1. Semi transparent: the persistent classes or properties need to be marked in some special way to be persisted (attributes, inherit from a special class or such…)

    2. Transparent: the classes don’t need to be modified at all to be persisted

Things get fuzzy, though. It is sometime unclear the difference between 2.2 and 3.1 and various creative solutions can be hard to classify. But in a general sense, this classification is probably about right. In a generic sense EJB1.1-2.0 is a 2.2, EJB3.0 is a 3.1, JDO is 3.2 (if you don’t consider post-compilation) and ObjectSpaces is a 3.2. Hibernate and Toplink are squarely 3.2.


But do you really need to go all the way to 3.2? All the times? I’ll try to post more about trade-offs in all these solutions, but if you have an idea of a better categorization, please let me know. The one I propose is right out of my head and I’m not to happy about it either.

I’m really an old, almost fat, beach volley player…

I used to play a lot, back in Italy. We would come out from work, go to the beach, play two or three hours, swim a bit and then go out for the night. This would happen about every day. We took it awfully seriously. We would go to the Italian national championships and all. It was quite a big deal.


Seattle, on the other hand, is not too conductive to beach volley. Not too many real beaches and all of them quite far (commute wise) from where I live. So I don’t play anymore, but I still like the game. One weekend or two each year, my wife and I go down to Los Angeles to watch AVP tournaments. And man, it is a lot of fun!!


And, by the way, beach volley has a lot going for it. For the players it is a low impact sport (the sand is soft). Plus you play the ball a lot, much more than in normal volleyball (or even soccer). Your are always in to the game, no place for hiding. It happens under the sun, so you don’t get all the nasty problem of not warming up correctly. And the environment… oh man!! You are on the beach, not in some crazy smelling gym somewhere. All in all, you got to love it….


Anyway, down memory lane…

Book: “Objects, Components, and Frameworks with UML”, Fedmond F. D`Souza

This is a book about Catalysis, an OO methodology. I read this book some time ago (like years…). It is a quite complex book. If you don’t like methodologists, it will easily put you to sleep. But if you stay awake, it is worth it.


It is strange how this book crystallized one concept for me: the definition of an interface. An interface is not just the sum of the signatures of the methods. It is a conceptual framework. The only way to fully describe it is to describe in a formal way this conceptual framework. For example without further specification it is impossible to know how to use this interface:


interface IBook() {


  void AddPage(IPage p);


}


What happens when you add a page? Will it add it at the end of the book? At the start? What happens if you call the method twice? Will the pages be in order? Will they be in the same section? Is there a concept of a section?


There are ways to make explicit the implicit model beyond an interface: the one that I’ve commonly seen being used is documentation. The book argues for formal contracts (preconditions, postconditions, invariants). The latter is certainly more formal, but to use it you need to describe formally what is the state beyond the interface and how the different methods affect this state. It is a lot of work.


Is it worth the effort? I guess it depends on a zillion things like: the type of project, the people involved, … I don’t think anybody is actually doing it, but it is still a good conceptual framework to keep in mind when you define your interfaces: it is not enough to write down the signature methods, you have somehow to expose the conceptual framework (where somehow means more or less formally).

I’m buying a house…

I think I’ve been misinterpreted in my previous posts. I’m not suggesting that renting is better than owning. You have to run your numbers and make your own choice. There are many assumptions to consider (financial and not). The not financial ones often are more important. You have to run your numbers, but in general renting looks better if:



  1. You cannot buy ( :) ) and/or

  2. You plan to stay in a place for a short time and/or

  3. You believe houses are vastly overpriced in your area and they’ll return will be negative for a while and/or

  4. You don’t want the psychological part of having a house (maintenance, tax payments, …)

In my case the most worrisome scenario is 3.


Back to our situation, we are buying a house for the pleasure of living in a particular location. Financially it is an OK transaction (fair price, I think).


I’ll probably post a little rent-buy spreadsheet as soon as I have time to refine it.


Thanks for all the good comments.