Shadowlessness

That’s my birthday, if you where wondering.
(Just a quick fact: this year, due to incompatibility of Gregorian and Persian leap years, and the relative inaccuracy of the former, my birthday was October 27th.
As a friend mentioned, my 28th birthday was not on the 28th of the month. In fact, as she again noted, the first time my age turned perfect after I knew what it was, I lost my perfect birth day of the month.)
Anyway, last year I found out that my birthday is the same with Bill Gates. This year, I was cursing my bad luck when I stumbled upon the fact that I share this birthday with Mahmoud Ahmadinejad. Sharing anything with the guy is anything but an honor by default!
Here are some fun facts about my birthday:

1. There are 64 days in a year after October 28th!
2. I have the exact same age (±24 hours) with the Czech football player Milan Baroš. I’ve known this for several years now, but I don’t know how. My best guess is IMDB!
3. John Romero is born on this day. Since we are in the same business (behold the shameless arrogance!) I must include him here. I firmly believe that “id Software” would still be making great games (as opposed to great engines only) if he were still with them. (Incidentally, this is one of the few posters that I’d be willing to hang in my room instead of James Hetfield’s Jolly Roger pose poster.)
4. John Locke died on this day. No, not that John Locke, this John Locke! (Sorry, couldn’t resist a “Lost” reference.)
5. A guy named Landon Curt Noll has this birthday too. I knew him from the IOCCC (he is called chongo over there.) (Warning: if you think you know C, and are not ready for a rude wake up, don’t go there! Here’s the Wikipedia page for a milder kick) but apparently he is quite a diverse person!
   Also, we used the FNV hash function (co-authored by him) in the “Silent2″ project (maybe 10 people in the entire world know what that is!) without me realizing who he was. Alas, I had to abandon that project, which I regret to this day, since the concept and opportunity were both very unique.
6. A whole bunch of other stuff have happened on this day, some of the most famous of which can be viewed on or accessed through the Wikipedia page.

The Soshiant website just went live. (UPDATE: Here’s the English homepage.)
And again, we are pulling an all-nighter to ready everything for the exhibition that opens tomorrow. This will be the first time that the public sees our baby, and you could imagine how excited we are.
However, there’s still a long road to go for Soshiant to become anything resembling a playable game. What we currently have is basically nothing more than a techdemo of some of the stuff that we could do, with time and of course, money.

Anyways, the exhibition is held at Tehran Mosalla. It starts tomorrow (October 22nd, Aban 1st) and goes on for 10 days. I’m told that the visiting hours are from 9AM to 9PM. If you are interested in posters, collector cards, T-shirts and some in-game and technology videos, concept art and our game, please give us a visit. We will be at “Fan-afzar Sharif” booth.

(UPDATE: Added the 6th item.)

I’m a fan of C/C++ preprocessor macros. I would be very happy if C++ received macros on par in power with those of Common Lisp macros, but that’s only a dream! We have to work with what we have.
Anyways, with use of macros come a lot of potential pitfalls. I’m going to go over a couple of them. I’m sure any C++ programmer is aware of these, but the reiteration would hurt now, would it? I’m also hoping that with your feedback, we can complete these into something referable and usable.

1. Operator Mishaps From Hell!
   This is a classic example.

   #define SQR(x)    x * x

   Imagine what happens when you use something like SQR(a + b). But as I said, this is a classic example, and any C programmer with half a brain should know enough to avoid this (doesn’t mean it always happens though. We all have our shameful secrets!)
   The moral is: always enclose every usage of macro parameters in parentheses as well as the whole thing. (#define SQR(x) ((x) * (x)))

2. The Space From Hell!

   #define SQR (x)   ((x) * (x))

   Notice the space between SQR and the (x)? The programmer didn’t! It usually results in a cryptic compile error about something not being a function or about incorrect number of arguments. Easy for more experienced programmers to understand and rectify (usually with a bang to their heads.)
   Also, it’s not hard to imagine cases without any compile errors and severe oddities in runtime behavior. Remember: Compile-time errors and warnings are your friends as long as you pay attention to them! They might be a little hard to understand, but a project with 100 pain-in-the-neck compile errors is better than 100 hidden runtime bugs just waiting to cut your neck off.

3. The Semicolon From Hell!
   Let me demonstrate the perils of the semicolon.

   // A macro to increment a counter, and wrap around to zero is a limit is reached.
   #define ADVANCE(x, wrap)    ((x) = ((x)+1)%(wrap));
    
   // Usage 1
   while (should_go_on)
       ADVANCE(i, 100);
    
   // Usage 2
   for ( ; should_go_on; ADVANCE(i, 100))
   {}
    
   // Usage 3
   while (should_go_on)
       p = ADVANCE(i, 100) + 100;

   As long as you stick to the first usage (i.e. as a statement,) you get away with your mistake (the spurious semicolon at the end of the macro definition.) However, usage 2 won’t compile. But this is a good thing, since you will know that you have an error in your macro (of course, if you’re a newbie in C++, it may take you quite a few minutes to figure this one out.)
   Usage 3 is where things get interesting. The code will compile (at most with a mysterious and seemingly unrelated warning,) but it won’t do what you think it does. That can be a bitch to track down.
   So, the moral of this story is: don’t put semicolons in macros!

4. The Multiple Evaluations From Hell!

   #define SQR(x)    ((x) * (x))

   What happens when you evaluate the value of SQR(++a)? Does that seem alright to you? (By the way, any one who tells you a += b is equivalent with a = a + b is either a moron, or thinks you are a moron!)
   The lesson of this item is: don’t use macros as fast, generic functions! Use inline templates (which are even potentially faster (do you know when? )) Like this:

   template <typename T>
   inline const T & sqr (const T & x) {return x * x;}

5. The Multiple Statements From Hell!
   The following macro deletes a pointer and sets it to 0, a very sensible thing to do nearly all the time.

   // This is not OK. Don't use this macro like this. Keep reading down this article!
   // Also note that I've not placed a semicolon at the end.
   #define SAFE_DELETE(ptr)  delete (x); (x) = 0
    
   // Usage 1
   char * s = new char [42 + 1];
   ...
   SAFE_DELETE(s);
    
   // Usage 2
   if (some_condition) SAFE_DELETE(s);

   But it doesn’t work, does it? I mean, usage 1 is OK, but you’ll wish you were never born when you have to stay up late into the night and debug the results of the second usage, won’t you? So, what do we do? I imagine everybody’s first response would be:

   // This is not OK, still.
   #define SAFE_DELETE(ptr)  {delete (x); (x) = 0;}
    
   // Usage 3
   if (some_condition)
       SAFE_DELETE(s);
   else
       doSomeWork (s);

   See the problem? No? The problem is in the semicolon before else. C++ doesn’t let you put a semicolon after an closing curly brace (’}') and before “else”. So what do we do? This is one of the solutions:

   // This is almost OK, and usable if you are not very picky.
   #define SAFE_DELETE(ptr)  do { delete (x); (x) = 0; } while (false)

   That’s right! We put the multiple statements inside a do/while block that is guaranteed to be executed only once! Brilliant, isn’t it? Well, I didn’t come up with it. I wish I could say that I though of it independently, but that’s not the case. I saw it in kernel code even before I had run into this problem! But the code didn’t say why it was used this way, and analyzing and discovering the purpose of this small piece of code was one of my biggest “Aha!” moments in C programming.
   So, we are good to go, right? Well, not quite. If you don’t care much about warnings the compiler gives off, you are good to go. But the above code results in a warning (only when you have turned the compiler warning level to the highest degree,) that the used condition is constant. Although the occasions for this warning are intentional most of the time (like here,) it may be the case that the compiler is warning us about a typo. Because of this, I don’t want to disable this warning (unlike those blasted 4996 warnings Visual C++ gives off like candy on Halloween, which I shut off with a wide and hysterical grin, while caressing my ax handle!)
   So what do we do? The best solution that occurs to me is like this:

   // We define a function that always returns false
   namespace __useless {
   inline bool i_am_false () {return false;}
   }
    
   // Now we use the above function instead of hard-coding the constant expression
   #define SAFE_DELETE(ptr)  do { delete (x); (x) = 0; } while (__useless::i_am_false())

   We trick the compiler here. The compiler is wise enough (or not smart enough) to give a warning no more, but any optimizer would optimize the overhead of the function call away completely.

6. The “if” From Hell!
   Suppose we “optimize” the above SAFE_DELETE macro, to check whether the argument is NULL, and do nothing in that case.

   #define SAFE_DELETE(ptr)    if(ptr) delete (ptr), ((ptr) = 0)
   // Note that I've incorporated the comments from Hadi (comment 2) here, to make a point.
    
   // Usage 1
   if (some_condition)
       SAFE_DELETE (s);
   else
       return 0;

   Ouch! That hurts. I don’t think there’s anyone who doesn’t know this already, but in case there is (almost no shame in not knowing,) the “else” in the first usage will be the else clause for the “if” inside the macro! You are going to hate Dennis Ritchie after the first two hours of bewilderment over this (but of course, that would be out of frustration, and without logical cause!)
   You may be tempted to solve the problem like this:

   #define SAFE_DELETE(ptr)    if(ptr) {delete (ptr); (ptr) = 0;} else {}

   But don’t! Do this:

   #define SAFE_DELETE(ptr)    do { if(ptr) {delete (ptr); (ptr) = 0;} } while (__uselss::i_am_false())

   The moral? If you write “if” clauses in macros, be extra careful.

The above were only some of the pitfalls, but I can’t continue right now. Looking forward to your suggestions. Don’t be shy!