Coding Away

One rainy day you write some code in C++, and compile it with no errors. It might just work, you hope. You run it and it just doesn’t do what it should be doing. You debug it, look at it, think about it, tweak it… but… nothing! You try to understand. The code is there. Only a few lines, doing something that doesn’t seem right.

[Am I going mad?]

typedef enum
{
	FIRST_ONE,
	SECOND_ONE,
	THIRD_ONE
} T_states;

int main()
{
	T_states x=FIRST_ONE;

	switch(x)
	{
		FIRST_ONE:
			printf("First one! Yeah.n");
			break;
		SECOND_ONE:
		THIRD_ONE:
			printf("Second or third one?n");
                        break;
		default:
			printf("None of them!n");
                        break;
	}
	return 0;
}

…you find yourself kneeling down in front of your desk with your fists ready to smash the screen… then… with your amazement… you figure it out… you completely missed the case… Bad words associated with the compiler pop to mind.

There are mistakes that you never made, and that you’d never think you would make. When you do make them, you just don’t see them, because everything looks so innocent and normal… except… that you missed the darn case…

Yep, the code above compiles just fine. No errors, at least not with VS and with another embedded compiler I’ve compiled it with. In fact, it is perfectly syntactically valid code. Evil, but valid.

When you run this code it prints “None of them!”. Yep. You missed the case!!!! (the “case” keywords before the constants inside the switch).

The compiler takes “FIRST_ONE”, “SECOND_ONE” and “THIRD_ONE” as goto labels, and doesn’t complain. Everything compiles. Obviously when you run it, the execution runs straight to the default case.

Never miss a case, especially when you are tired!!

The classic way of swapping to variables uses a temporary variable. In C++ it looks something like:

void swap1(int &a, int &b)
{
     int c=a;
     a = b;
     b = c;
}

Some developers can’t stand that they need a temporary variable to make the swap, and prefer to write:

void swap2(int &a, int &b)
{
     a ^= b;
     b ^= a;
     a ^= b
}

Assuming that a and b are pointing to different memory locations, this actually works.
It is based on the fact that [ (a^b)^a = b ] and [ (b^a)^b = a ]

While this seems like a cool trick, is it really worth writing it? Or should you stick with the classics?
I say it is not worth it! Stick with the classics!!!

In fact:

It is slower

swap1 requires 3 assignments.
swap2 requires 3 XORs and 3 assignments.

If you are not convinced, here is the assembly generated by VS for swap1 (you get similar results with gcc and other compilers):

6:    void swap1(int &a, int &b)
7:    {
00401030   push        ebp
00401031   mov         ebp,esp
00401033   sub         esp,44h
00401036   push        ebx
00401037   push        esi
00401038   push        edi
00401039   lea         edi,[ebp-44h]
0040103C   mov         ecx,11h
00401041   mov         eax,0CCCCCCCCh
00401046   rep stos    dword ptr [edi]
8:        int c;
9:        c = a;
00401048   mov         eax,dword ptr [ebp+8]
0040104B   mov         ecx,dword ptr [eax]
0040104D   mov         dword ptr [ebp-4],ecx
10:       a = b;
00401050   mov         edx,dword ptr [ebp+8]
00401053   mov         eax,dword ptr [ebp+0Ch]
00401056   mov         ecx,dword ptr [eax]
00401058   mov         dword ptr [edx],ecx
11:       b = c;
0040105A   mov         edx,dword ptr [ebp+0Ch]
0040105D   mov         eax,dword ptr [ebp-4]
00401060   mov         dword ptr [edx],eax
12:   }

While for swap2 the assembly generated by VS is:

14:   void swap2(int &a, int &b)
15:   {
00401080   push        ebp
00401081   mov         ebp,esp
00401083   sub         esp,40h
00401086   push        ebx
00401087   push        esi
00401088   push        edi
00401089   lea         edi,[ebp-40h]
0040108C   mov         ecx,10h
00401091   mov         eax,0CCCCCCCCh
00401096   rep stos    dword ptr [edi]
16:        a ^= b;
00401098   mov         eax,dword ptr [ebp+8]
0040109B   mov         ecx,dword ptr [ebp+0Ch]
0040109E   mov         edx,dword ptr [eax]
004010A0   xor         edx,dword ptr [ecx]
004010A2   mov         eax,dword ptr [ebp+8]
004010A5   mov         dword ptr [eax],edx
17:        b ^= a;
004010A7   mov         ecx,dword ptr [ebp+0Ch]
004010AA   mov         edx,dword ptr [ebp+8]
004010AD   mov         eax,dword ptr [ecx]
004010AF   xor         eax,dword ptr [edx]
004010B1   mov         ecx,dword ptr [ebp+0Ch]
004010B4   mov         dword ptr [ecx],eax
18:        a ^= b;
004010B6   mov         edx,dword ptr [ebp+8]
004010B9   mov         eax,dword ptr [ebp+0Ch]
004010BC   mov         ecx,dword ptr [edx]
004010BE   xor         ecx,dword ptr [eax]
004010C0   mov         edx,dword ptr [ebp+8]
004010C3   mov         dword ptr [edx],ecx
19:   }

This should make it clear how swap2 is less efficient than swap1.

Provides no real advantage

The only real advantage is the rush you get from having written a piece of unreadable code using cool tricks.

The fact that you save sizeof(int) bytes on the stack in 99.99% of the cases is not a real good reason to write swap2 instead of swap1. Perhaps it is advantageous in some recursive situation, where every byte in the stack counts and where you don’t want to make an extra function call to a swap function. I’d have to see such code to believe it.

It is not readable

I know. If you wrote it, you know what it does. But what about the rest of the world?
The problem is that for many others swap2 is not going to be readable and it is going to generate only confusion, not amazement.

In the long term it is far better to write readable code than some cool unreadable and inefficient piece of work.

Keep it simple!!

I can’t help it. I just love the nuisances of C++, and some of the weird things you can write with it.

From time to time I will share some of my favorite examples under “Useless Programming Interview Questions” (UPIQ) category.

Why did I pick this name? Well, the aspects of C++ that I am referring to allow you to write code so strange and unreadable that you’d never do it in real life! Right? The only time you might seriously consider these aspects of the language is if you are a twisted individual asking an useless interview question to a job candidate.

Why do I call these questions “useless”? Because the fact that the candidate knows the answer or not tells you very little about his or her skills. You’d better don’t waste precious interview time in such things. I know it’s fun, but I bet there are much better questions you can ask.

Useless Interview Questions:

Mr.Candidate, please look at this code:

int main()
{
	int a[3]={1};
	int b=1;
	int c[3]={0,2,1};

	a[b[c]]=2;

	printf("a[0]=%dn",a[0]);
	printf("a[1]=%dn",a[1]);
	printf("a[2]=%dn",a[2]);
	return 0;
}

1) Is this valid C++? Can you compile it?
2) If so, what is it going to print to stdout?

Answers:

(more…)

Let’s say that you have the following structure:

struct
{
     char *sPtr1;
     char *sPtr2;
} S_something;

In C it is very tempting to initialize such a structure with something like:

   S_something s;
   memset(&s,0,sizeof(S_something));

That code seems OK at first, but there is a subtle issue. Can you spot it?

The problem is that this code is not always portable!! Most of the time you’ll be fine, however depending on the system (in rare cases, I admit) a null pointer might not be represented by a bitwise zero, but something else. In fact in some architectures 0 is a valid address (Example: IBM z/Architecture)

When you use memset to initialize the structure above, you are forcing the pointers in the structure to be set to bitwise zero. As noted that might not be equivalent to null, creating all sort of issues.

Conversely, when you assign a pointer to “0″ or to “null” on one of these systems, the compiler does the conversion automatically. memset doesn’t.

I’ll give you an example. The following code:

   S_something s;
   memset(&s,0,sizeof(S_something));
   if (s.sPtr1==0) printf("Good");
       else printf("Bad!");

Could potentially print “Bad!”.

Solution: simply initialize the structure by hand:

   S_something s;
   s.sPtr1 = 0;
   s.sPtr2 = 0;

This is guaranteed to work on all ANSI C compliant compilers.