Archive for: March, 2005

Why patents suck

I found a great example why (software) patents suck on the IGDA homepage, and an oppressive feeling arises when I imagine what lawsuits like this mean for game developers and software engineers in general if the claim is admitted. A short excerpt:

There is an ongoing patent litigation case in the Eastern District of Texas of interest to all developers because of how broadly the Plaintiff appears to want to apply the claims of the patent. In this case, American Video Graphics, L.P. (“Plaintiff”) has sued sixteen game publishers, alleging that these defendants infringe AVG’s [patent], “Method and Apparatus for Spherical Panning.” […] Plaintiff has identified over 1000 accused games, which Plaintiff alleges infringe their [patent].

IGDA is now desperately searching for prior art to invalidate the patent. Read the full story here.

Exceptions and Stacktrace in C++

Today I was discussing about how one could implement a stacktrace in C++, where one has not the luxury of Thread.dumpStack() or Throwable.printStackTrace(...) of Java.

The general C++ approach one finds often is to create a dummy object on the stack at the beginning of each method which receives the current file and function as constructor parameters (using the __FILE__, __FUNCTION__ and __LINE__ macros) and stores them, i.e. increases a list pointer and saves the const char* at the resulting position. As soon as the object gets destructed at the end of the function, the list header pointer is decreased again.

So, my first implementation looked like this:

#ifndef FINAL
#define CALLSTACK CallStack dummy(__FILE__, __FUNCTION__)
#else
#define CALLSTACK
#endif
class CallStack
{
public:
    CallStack( const char* _file, const char* _function )
    {
        file[ current ] = _file;
        function[ current ] = _function;
        current++;
    }
    ~CallStack()
    {
        current--;
    }
    static void dump()
    {
        for( int i = current - 1; i >= 0; --i )
        {
            std::cout < < file[ i ] << ": " << function[ i ] << std::endl;
        }
    }
private:
    static int current;
    static const int MAX_STACK_DEPTH = 1024;
    static const char* file[ MAX_STACK_DEPTH ];
    static const char* function[ MAX_STACK_DEPTH ];
};
int CallStack::current = 0;

The first test with an exception I threw somewhere deep in the call hierarchy of my program revealed what one has to remember about exceptions: objects that exist on the stack at the time the exception is thrown are ordinary destructed. So, the d’tor of my CallStack object was called, too, and current was not pointing to where I had expected. So I had to mark the last element of my list in order to recognize it as the tail.

I decided to set the following element after current to 0 so that I would iterate through the elements until I reached 0 in order to dump the stack trace:

CallStack( const char* _file, const char* _function )
{
    file[ current ] = _file;
    function[ current ] = _function;
    current++;
    file[ current ] = 0;
    function[ current ] = 0;
}

I thought this would work fine, but a friend of mine pointed out this case:

void someMethod()
{
    CALLSTACK;
    foo(); // foo was called, end of list is still behind foo
    throw; // exception is thrown and the resulting stacktrace is misleading
}

So, it turned out that I had to move the tail-pointer back, too, but only in case no exception was thrown. Someone on flipcode had a solution which required all exceptions to descend from one base class which handled this situation, but I wanted to be able to throw anything. bool std::uncaught_exception() satisfied my needs. So, if we’re in the CallStack d’tor, and std::uncaught_exception() returns true, we know that the current method just caused an exception, so we don’t need to move the tail marker anymore. It’s just that simple. I used a static bool flag bool CallStack::exc = false; to remember this situation for the following d’tors. Of course, after one handled an exception one should reset the flag so that the following d’tors set the tail marker correctly again. One should also check whether MAX_STACK_DEPTH is reached (or use std::vector), but you’ll figure this out yourself.

Well, it’s late. If someone is interested, I can provide a full example, just let me know. I also appreciate c&c, indeed. I’m sorry if the source code is messed up, WordPress seems to do this. Night.

GTK Font Size

Although I’m not a Linux geek, I play around with it from time to time. I have a Gentoo installation on my notebook. One might argue about the different distributions, but I found this one to be the most intuitive among the ones I tried.

Today, I updated to the current Eclipse 3.1 M5a milestone, which I use at work, too. I had no trouble with this version yet, and if it’s good enough for work, it’s fine for using it at home, isn’t it? I did not use portage, but downloaded the GTK 2 binary instead.

One thing I disliked was the huge font size. I was able to customize most font sizes in the Eclipse options, but the main menu remained in its original way-too-large size. I found out that this was some kind of GTK default font, so I searched for a way to change it, and found a little handy tool called gtk-chtheme. I downloaded it using emerge gtk-chtheme and was then able to change this main font easily. Now everything suits my needs, and I surely will use Linux for development more often.

Short rant: for a long time, Visual Studio was my favourite IDE; then, I got to know Visual Assist and thought that VS alone was quite limited; then, I started to write Java code for a living and thought that Eclipse was an even more powerful IDE (a big plus are the great refactoring possibilities of Java, so this is not a real IDE argument); now, I got to know IntellJ IDEA and I’m looking forward to having the $499 bucks to spare. But I guess until then Eclipse ripped off all the great features 😉

Bureaucracy rocks

I am currently working on a review of Diomidis Spinellis’ book “Code Reading – The Open Source Perspective”. I found a nice quote at the beginning of chapter five, “Advanced Control Flow”:

“It is necessary for technical reasons that these warheads be stored upside down, that is, with the top at the bottom and the bottom at the top. In order that there may be no doubt as to which is the bottom and which is the top, it will be seen to it that the bottom of each warhead immediately be labeled with the word TOP.”
(British Admiralty Regulation)

Had a good laugh when I read that 😉