All posts in Software Engineering

Now the people at SlickEdit® released a package of VS2005 enhancements, too. More info.

Other todays favourite links are openadaptor.org, bloodmasters.com and TiddlyWiki.

Microsoft has released a Power Toys package for VS2005.

Visual Studio 2005 IDE Enhancements are a set of Visual Studio extensions that are designed to make you more productive. These enhancements are directly integrated into the Visual Studio IDE. This set of enhancements includes Source Code Outliner, Visual C++ Code Snippets, Indexed Find, Super Diff and Event Toaster tools. All these tools except the IDE Event Toaster can be invoked from Visual Studio’s View.OtherWindows menu group. The Event Toaster tool can be configured from the Tools Options dialog under the PowerToys node. The Visual C++ Code Snippets can be invoked on any C++ source file. Previously, these enhancements were only available via the Visual Studio 2005 SDK. This installation does not require Visual Studio 2005 SDK.

• Source Code Outliner: The Source Outliner tool is a Visual Studio extension that provides a tree view of your source code’s types and members and lets you quickly navigate to them inside the editor.
• Visual C++ Code Snippets: The Visual C++ Code Snippets tool lets you insert snippets in your code by using a pop-up menu that contains programming keywords. VB.NET and C# languages have this functionality in Visual Studio 2005.
• Indexed Find: The Indexed Find tool is a Visual Studio extension that uses the Microsoft Indexing Service to provide improved Search capabilities to the integrated development environment (IDE). It sends the results of a search to the Output Window.
• Super Diff Utility: The Super Diff Find tool is a Visual Studio extension that compares text files. It uses color coding and graphics to show the difference between the files in deleted text (red), changed text (blue), inserted text (green).
• Event Toaster Utility: The Event Toaster tool is a Visual Studio extension that notifies users about specific events within the Visual Studio IDE.

Taken from here.

I just had a case where I wanted to make sure that a C++ template parameter was of a certain type. The template should be used for pointers to instances of class “Base” and its derivates so that I could call a method of Base on the object provided to the template class.

template< class T >
class MyTemplate
{
public:
    MyTemplate( T object )
    {
        object->baseClassMethod();
    }
};

First, I thought there would be no way to achieve this, but then I tried a static_cast which turned out to be the solution: using the static_cast ensures that the type casted to is used at compile-time. Isn’t that beautiful? If you don’t need to access the object but constrain the template to a certain type, you could use the d’tor to implement some dummy code.

template< class T >
class MyTemplate
{
public:
    MyTemplate( T someObject )
    {
    }
    virtual ~MyTemplate()
    {
        // constrain parameter type to "Base"
        // and derivates
        static_cast< Base* >( static_cast< T >( 0 ) );
    }
};

Using this template with a type which is neither “Base” nor inherited from “Base” leads to a compiler error like “can’t convert ‘bad type’ to ‘Base’.

I just read something in AI Game Programming Wisdom 3 which sounded sooo familiar to me. Sergio Garces of Pyro Studios writes about game architecture regarding the game objects, “… we often see examples of inheritance abuse, making the fundamental mistake of confusing behaviour (what objects do) with identity (what objects are)”. This is exactly one of the many mistakes I did in DVW, where the inheritance hierarchy is like Entity<-Unit<-Vehicle<-Constructor<-KPBConstructor or Entity<-Unit<-Building<-UnitFactory<-BunkerBarracks. It works, but this really is not the way I would do again. Next time, I would use a part-based approach like sheijk|6S is doing in Velox3D, i.e. the game designer (not necessarily the programmer!) creates units out of several abilities, just like plugging and playing: plug in a motor, and the entity could move; plug in a weapon, and the entity could attack or fight back; plug in a brain (i.e. some AI) and it knows how to use its parts.

But we’re making good progress anyway.

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.