Campus Ambassador Coordinator Around the Sun

Over the weekend I saw what I considered to be an interesting e-mail on one of the various mail alias I am subscribed to. This e-mail was basically titled 'Error in the Java compiler?' and said the following...

Hallo all,

Why do different results come out with the program 2? From my point of
view A and b must agree. The lines are semantically alike. The operator
++ binds more strongly than +

public class Main {
    public static void main(String[] args) {

        int b, a;

        b = 2;
        b = ++b+b;

        a = 2;
        a = a+++a;

        System.out.println("b: " + b);
        System.out.println("a: " + a);

    }
}

Output:
run:
b: 6
a: 5

The answer to me was quite obvious. The user simply hadn't realised that a++ and ++a are different in so far as a++ will use the current value of a for whatever it is currently doing, then it will add 1 to a. ++a on the other hand will add 1 to a and then use the new value of a.

        2+1 + 3
++b+b = b+1 + b = 6

        2   + 3
a+++a = a++ + a = 5

However, it then turns out that the example provided wasn't really appropriate and as such the user sent a new e-mail, this time with the following example:

Naturally this again was not an error in the Java compiler. It was due to the Java specification which says that all expressions are evaluated from left to right. As such, in the second example we evaluate a to be 2 first, and then we times that by ++a, resulting in 6...

2+1 * 3
b = ++b * b = 9

    2 * 2+1
a = a * ++a = 6

The most interesting thing about this whole subject is that if you were to write that kind of code in C it would be completely undefined in terms of what the results would be. The compiler writers may do their best to come up with sensible solutions, but some times you'll get 9, other times you'll get 6 and for that matter some times you could get -99,938 or even 2,394,343 etc.

So - what is the moral of all this - don't write code like that. Do it in two separate statements. That way the code is clearer and the outcome is more predictable.

Something  I learned today on my Advanced Crash Dump Analysis course that I've never thought about before was how we can improve the performance of our programs just by re-ordering our variables in data structures. Whenever you write something like the following in C you naturally use up memory:

	struct unpacked {
		int a;
		char b;
		int c;
		char d;	
		int e;
	};	

The above structure (we can assume), will use up 20 bytes of memory due to the padding. This is due to the way the structure is layed out in memory. Assuming that we're using a Intel processor and that we are storing our values in memory in multiples of the sizeof() the item we're storing, if we were to look at the memory layout for the above struct we'd expect to see something like the following:

int a	int a	int a	int a
char b	pad	pad	pad
int c	int c	int c	int c
char d	pad	pad	pad
int e	int e	int e	int e

However, assume this time that we program the struct as follows:

	struct packed {

		int a, c, e;
		char b, d;

	};

Well, now we've reduced the amount of space used to 16 bytes - and no it's not because I've removed those line breaks! Instead of wasted space in memory between those ints and chars we're using the space more wisely. The new layout in memory would be something like the following:

int a	int a	int a	int a
int c	int c	int c	int c
int e	int e	int e	int e
char b	char d	pad	pad
free	free	free	free

Naturally there will be instances where you don't really have much choice how you order your structs - especially when dealing with hardware or predefined protocols by other people or organisations. Indeed, the performance gains may not even be that big - but it just peaked my interest and so I thought I'd share it with you :)