Consider the following 3 for-loops in C/C++:

Best Practice: If the value of ‘n’ is not supposed to change throughout the lifetime of the loop, then I think everyone can agree that using const in Loop 3 is a best practice. This helps ensure that some other coder doesn’t muck about with the loop’s end condition inside the loop (since it will be flagged with a compiler error).

Optimization: It makes sense that, in general, Loop 2 would execute faster than Loop 1. But I was curious if a compiler could optimize Loop 3 to make it run faster than Loop 2? It’s been awhile since I looked at any assembly output, and my compiler theory has always been rather weak, so I thought I’d throw the question out there in case anyone has a clue…

When using the C++ Standard Template Library, one has to be careful not to invalidate iterators in a container that you’re iterating over. If that makes any sense to you, then

A colleague of mine had code like this:

You might be surprised to hear that the program crashed when the first task had to be removed. The reason is that the removeTask() function erases an item out the collection which invalidates the iterator loopit. When the for-loop tries to increment the iterator, we get unexpected results.

This is a frustrating problem, but it can be solved. In short you have to:

• grab the iterator that is returned from the erase operation
• set your loop iterator to that returned iterator
• change from a for-loop to a while-loop (to ensure that your loop iterator is not incremented when a task is removed)

Here is the modified code:

I’ll get into how you can actually code with Luabridge in a later blog post – once you’ve got it all linked in, it’s really not that hard.

I’ve really only started using Boost.Filesystem very recently to replace some platform-specific code that accessed the file system so that I could port my code over to OpenSUSE (Linux). That change was pretty much the only thing I had to do because the rest of the program relies on SDL which is already cross-platform.

The code I was using was originally ported from DOS to Windows and used the functions _findfirst(), _findnext() to access a directory contents, iterate through each file and find all files ending in a specific extension. A pretty common operation really, so I thought I’d post this as an example to get people looking at Boost.Filesystem:

#include <string>
#include <vector>
#include <boost/filesystem.hpp>
using namespace boost::filesystem;
using std::string;
using std::vector;

  // get all files ending in .tsg
  vector< string > filenames;
  path dir_path("data/savegame/");
  directory_iterator end_it; // [1]
  // loop through each file in the directory
  for(directory_iterator it(dir_path); it != end_it; ++it) {
    // if it's not a directory and its extension is .tsg [2]
    if( !is_directory(it->status()) && extension(it->path()) == ".tsg" ) {
      // store filename for later use
      filenames.push_back( it->path().string() );
    }
  }

Now your filenames vector contains all the filenames in the directory “data/savegame/” that had an extension “.tsg”. Some notes on this example:

1. By default, a directory_iterator usefully points to “past the end”
2. Extensions are case-sensitive on Linux

So basically, a path is pretty much what you’d expect: a location in the filesystem which can either be a directory or a file. You can get the full string representation by calling the member method string(). A directory_iterator allows you to iterate through all items in the path. There are some convenience functions like extension() and basename(). The leaf() member function of a path returns a string holding the last file or directory name in the path object if you ever need that.

Weaning Off The Microsoft Juice

As a hobby, I develop in Linux these days using KDevelop. For Windows, I still use Microsoft’s Visual C++ because Developer’s Studio is still one of the best IDEs I’ve come across for Windows. Doug just released a self-contained Eclipse CDT plus MinGW compiler. If that doesn’t mean anything to you, so be it – but it’s something I’m excited about. Looks like he also acknowledges that Eclipse CDT can be slow/sluggish so probably still lots of work to do. I should get around to testing this one day. If you code C/C++ in Windows – what do you use?

Organizize Your Google Docs

Google Docs updates allow you to now organize your documents into online folders – and the web browser inches a little closer to a platform that replaces things you do with your operating system…

Google Maps Snaps

Via Download Squad, Google Maps has added an awesome new feature. Now if you don’t like the directions that you get, you can click and drag to change your route. The blue directional route snaps to the streets that you will have to take. Pretty impressive stuff (though I did notice that if you click and drag enough it can get pretty confused – I’m sure they’ll refine their snapping/merging algorithm).

I was surprised to learn from this article that the next version of C++ won’t likely be ready until 2009. They’ve been batting around ideas for this version for awhile (the last version of C++ was C++98). On one hand it’s great that developers and compiler/IDE implementors will be able to keep up with the new versions of the language. On the other hand, it seems to cast a negative shadow on the slow-moving process when compared to other technologies (like web technologies for instance). After all, a lot happens in 3 years (let alone 11 years) in the technology space.

According to Stroustroup, the committee is made of up volunteers who all have “day jobs”, so that explains the pace to some degree. Anyway, I somehow get the feeling that the process is moving at a deliberate pace to give time for the market to absorb changes from the last version to see what worked, what didn’t and what needs are out there. I don’t think the C++ committee feels they need to compete with other technologies since C++ is so well-established in its very wide niche. This isn’t to say that C++ doesn’t need an upgrade – I agree with Stroustroup, the overall syntax for generic programming in C++ currently sucks (not a big surprise since, if I understand things correctly, generics were thrown in almost as an after-thought in the original C++ design).

Anyway, the underlying goals of committee are noble:

• Provide stability and compatibility (with C++98, and, if possible, with C)
• Prefer standard library facilities to language extensions
• Make only changes that change the way people think
• Prefer generality to specialization
• Support both experts and novices
• Increase type safety (by providing safe alternatives to currently unsafe facilities)
• Improve performance and ability to work directly with hardware
• Fit into the real world

Stroustroup doesn’t give away much, since nothing is absolutely firm yet. But here’s an example of some code that would align with some of the things he talks about:

Proposed C++0x code:

Equivalent C++89 code:

I know which version I prefer!

The idea of the “auto” is great – it means “figure out which type I need”. This is fantastic for iterators like the above example – now if I change my underlying container to a std::list, I don’t need to change the iterator type (or write a typedef for it), the compiler will pick up the change automatically. Of course you could use the C++98 version if you want to automatically typecast the iterator to some other type but clearly the “auto” idea makes great sense. Anyway, the idea is to eliminate all that unnecessary typing: Why should I have to do all that typing when vec.begin() returns a std::vector<double>::iterator in the first place? I welcome this addition to the language but it may make some programmers lazier in the long run. I can just see people putting “auto” every place instead of looking up the return types of functions and then getting into trouble with casting operations later – hopefully compiler warnings will keep us in line.

The ability to initialize a user-defined container via a list is less important to me, but it is appreciated since it puts user-defined containers almost on par with arrays and structs.

Stroustroup also mentions the idea of concepts which he describes as a “type of a type”. In this facility, you specify within a template declaration what properties a template argument must have in order to be properly used within a template. This is used today, I remember Alexandrescu’s Loki library as described in “Modern C++ Design“, which uses this heavily. But if I understand Stroustroup here, the proposed where clause would allow for less cryptic compiler error handling up-front and to disambiguate “between templates taking the same number of arguments”. I’ll be interested to see this one when it’s fully baked because, as a C++ geek, I’m obliged to be a fan of generic programming

Stroustroup also mentions many of the libraries he would like to see in the next version of the Standard Template Library (STL). I’d personally like to see all of the following standardized now (that way I wouldn’t have to worry about including the correct header files in my projects):

• Boost.Filesystem – for dealing with directories and files
• Boost.bind, Boost.mem_fn, Boost.Function – for function binding, callbacks
• Boost.Thread – for multi-threaded programming
• Boost.Spirit – for inline parsing of EBNF grammars

You could make arguments that Filesystem and Spirit are outside the core language principles and should stand as separate libraries, but this is my pet list after all so nyah!

I decided to start by porting another simpler game written by Sinasac (“Caverns of Xaskazien”). The original codebase of “Caverns” was C and clocked in under 5000 lines. Once I set up a C++ project, linked in a stub of the BOSS library, corrected various compiler errors and warnings that were no longer “correct” (the Borland compiler strictness of the early nineties were pretty lax compared to today), the game actually compiled and ran. Then I started filling in the BGI functions that I needed by writing them using C++ and SDL. You can see the early development timeline of BOSS here. I wrote the basic workable BOSS library and ported the “Caverns” code in 5 days and handed the “Caverns” code back to Sinasac two days before my wife gave birth to our two wonderful baby boys. Yes, I know I should have been rubbing her feet that whole time…

Note that I only wrote the BOSS functions that the game needed, no more. My goal in the BOSS library was only for porting the existing games, not for being “feature complete”. I think this was really the start of my newer philosophy on development: Set smaller goals and march towards them, don’t get distracted and don’t try to engineer the ultimate generic solution. This eventually morphed into: Do incremental steps to achieve what you want, while always providing a fully functional app (something akin to the “Small Releases” goal in eXtreme Programming methodology). The focus on delivering builds that are always fully functional keeps my goals smaller and more incremental, but gives me a better chance of actually achieving them, given my limited free time to work on this stuff.

Anyway, the success of the initial stages of BOSS got me working on expanding it to include old-school keyboard handling like getch(), bioskey(), kbhit() and to implement a sound subsystem that originally came out of “The Black Art of Game Programming” (Andre Lemothe). All of it done in SDL with little problems (implementing bioskey() and getch() proved to be the most challenging). With all these things packed into BOSS, it was fairly usable as a “guts replacement” for the old-school C libraries that the games used and it was fairly straightforward to set up “Ten Nights” to use BOSS.

I’m done with Boss now. If someone wants to finish BOSS up, I would open source the project, but I can’t imagine the call for such a thing would be very strong. Borland’s BGI libraries are already more than a decade obsolete.

You see, the usefulness of BOSS is only for porting old applications that relied on these ancient libraries, it is hardly useful for more modern game programming. For that, it makes sense to use SDL directly for both maximum flexibility and speed.

With that in mind, I started out restructuring “Ten Nights” to use SDL directly, moving functionality piece-by-piece to use SDL directly (instead of the BOSS wraparound).

Then…. well, my kids were born… so the pace slowed down quite a bit… (hear the crickets chirping?)

More on SDL development for games in Part Three.

So for the past week, I’ve been hacking away at the code for Ten Nights of Killing and Mayhem when I have some free time. Development is also being spurred on by the fact that Jeff Sinasac has some time to generate some new sounds and graphics for the game. Fresh resources are always good incentive to get more work done.

“Ten Nights of Killing and Mayhem” was originally a board game that Sinasac and I designed (with the invaluable help of a few others) in high school (1991). In retrospect, the subject matter is hardly politically correct, maybe even disturbing, but it was a fun creative outlet for us during a time when we needed it. About a year later (1992-ish), Sinasac wrote “Ten Nights” as a DOS-based game. Then maybe a year or two after that he rewrote it to use enhanced graphics/sound (though still DOS-based). By this time the game resembled a primitive top-down X-Com in its gameplay and approach.

The DOS-based game used the Borland graphics libraries (Borland Graphics Interface or BGI), but since the migration from DOS-based systems to Windows-based systems in the mid-nineties, such graphics libraries are long past their point of usefulness. With the advent of modern media technologies, something new was needed.

Porting directly to DirectX was one option, but DirectX is heavily COM-based and would have required drastic rewrites of a non-trivial codebase. My goal was to get “Ten Nights” up and running as quick as possible in Windows (and then later enhance it).

Simple DirectMedia Layer (SDL) is similar to DirectX in that it providing access to graphics, keyboard/mouse event handling, audio, etc for games. Yet SDL is a cross-platform library and is (therefore) not dependent upon the user worrying about COM, Window handles, display context, and the like. In essence, you can disengage from learning heavy platform-specific code and, once you know a little SDL, just work on your game. You also have the side benefit of easing ports to other platforms.

Actually SDL’s approach to 2D graphics is fairly minimal. It allows you to configure your video settings (resolution, colour depth), load images (Windows BMP only), obtain pointers to surfaces that represent image data (both onscreen and in-memory), and perform blits to the screen. The blits can be standard copies, colour-keyed copies (to provide simple transparencies or sprites) or more complex alpha-blended blits (to provide opacity and blending effects). There are a couple other lesser-used functions in SDL, but from a graphics perspective that’s about it.

In some respects, since SDL needs to be cross-platform, it (unfortunately) needs to provide a “least-common denominator” approach for basic graphics support. For instance, SDL does not even provide a function to get or set an individual pixel colour, you actually have to write your own (or use the code provided in the SDL documentation here). However, it makes up for this sparseness by providing hardware accelerated support on platforms that can do this (for example, SDL uses DirectDraw on Windows platforms for fast hardware support on video cards that support this). SDL also has some good extension libraries you can add onto that provide you with richer functionality (more on these in later entries).

In addition, SDL provides the benefit of allowing you to handle events (keyboard, mouse, timer, joysticks) and audio in a cross-platform manner, which is a huge benefit if you’re thinking of writing games once that can run everywhere. You can pick and choose the components that you need from SDL and there’s not a lot of complicated “initialization” steps that need to happen before you can do something useful.

SDL does not provide support for 3D graphics, but it does integrate nicely with OpenGL. For example, you could use SDL to handle all your window initialization, event-handling, audio and then use OpenGL for your 3D graphics.

SDL is pretty easy to pick up since there’s not a lot of complicated things to learn. Everything is straight-forward C-style API calls and you’ve only got to learn about a few structs (the most important of which is SDL_Surface) before you can start doing something useful.

Anyway, weighing the pros and cons of SDL, early March 2004 I decided to learn about SDL and work towards porting the old games to SDL. Was it spurred on by my anxiety related to my wife being due with twins that month? Was this my last-ditch attempt to reclaim my geek programming life and relive my high-school glory days before I became a family man? More coming in Part Two…

Anyway, when creating a new class where objects of that class need to be copyable, the first thing I ask myself is:

1. Is the new class a Plain Old Data type?

My definition of a Plain Old Data type (“POD”) is one that simply includes a fixed amount of publicly accessible data. This rules out anything that would include a member function, anything that has any dynamic memory allocation aspects and anything that would have protected/private data members.

If so, designing the class can be quite simple. I don’t need to worry about:

• copy constructors
• assignment operators
• destructors


class DatabaseRow {
public:
  unsigned int Id;
  unsigned short Year;
  char FilmName[255];
  
  DatabaseRow(unsigned int _id, unsigned short _year, const char* _filmName)
    : Id(_id), Year(_year)
  {
    FilmName[0] = 0;
    if(_filmName) {
      if(strlen(_filmName) < 255) {
        strcpy(FilmName, _filmName);
      }
      else {
        memcpy((void*)FilmName, (void*)_filmName, sizeof(char) * 254);
        FilmName[254]=0;
      }
    } // if(_filmName)
  } // end constructor
};


The compiler will supply hidden default (no-argument) constructor and a copy constructor for the above class which will work fine (since all data members are fixed length, no dynamic memory allocation takes place). There is also no need for an explicit destructor since all data members are automatically destroyed.

2. If not a POD, will I really need to copy objects of this class?

Sometimes it’s obvious when you will need to do copies, other times it’s not so obvious but it becomes convenient. For instance, if I want to avoid having to allocate and (remember to) de-allocate memory at runtime for an object I sometimes want to make it part of a class. i.e.:


class C1 { ... }
  
class C2 {
  
  C1 objectOfTypeC1;
};


In the above, I want C2 to contain an object of type C1 when C2 is instantiated. I don’t want to have C2 contain a pointer to C1 and then have to allocate a C1 inside C2′s constructor then remember to de-allocate a C1 when C2 is destroyed (lest I cause a memory leak). Any time I can avoid having to keep track of a pointer, I usually try to (though smart pointers can ease this task and static allocation really has become just a preference of mine).

Another scenario is when you have an array of objects:


class C3 {
  C1 anArrayOfC1s[2085];
};


Now an object of type C3 contains an array of 2085 C1 objects which are allocated when the object of type C3 is instantiated.

One problem with doing the above is that the C1 objects are statically created when the enclosing class is created using a default (no-argument) constructor. Often-times objects of the contained class (C1) cannot be constructed meaningfully at the time of the enclosing class’ (C2) instantiation, especially if it’s during program startup as opposed to at run-time.

Ultimately, this means you cannot specify any details about the individual C1 objects and often need to “initialize” those objects at some later state (a messy approach) or “reconstruct” those objects and copy them back to data members of the enclosing class.

For scenarios like this, it means I will supply the following:

• A copy constructor
• An assignment operator

I usually throw in a default, no-argument constructor and a destructor at this point too. Here’s my standard approach for this, which I’ve been using for a couple years now:


class DataBaseTable {
private:
  string Name;
  vector<DatabaseRow> Rows;
protected:
  bool deepcopy(const DataBaseTable& rhs) {
    bool bResult = false;
    if(&rhs != this) {
      this->Name = rhs.Name;
      vector<DatabaseRow>::iterator it = rhs.Rows.begin();
      while(it != rhs.Rows.end()) {
        this->Rows.push_back(*it);
        ++it;
      }
      bResult = true;
    }
    return bResult;
  }
public:
  DataBaseTable() : { Name[0] = 0; }
  DataBaseTable(const DataBaseTable& rhs) { deepcopy(rhs); }
  DataBaseTable& operator=(const DataBaseTable& rhs) { deepcopy(rhs); return *this; }
  
  const DatabaseRow& getRow() const { ... }
};


We supply a member function called “deepcopy” that ensures all data members are properly copied from “rhs” to “this” in a proper fashion.

The reason I return bool from this function is so that with a hierarchy of classes (all of which must be copyable), I can reuse the base class’ deepcopy as a starting point. For example:


class Base {
private:
  int arrayLength;
  int* someArray;
protected:
  bool deepcopy(const Base& rhs) {
    bool bResult = false;
    if(&rhs != this) {
      this->arrayLength = rhs.arrayLength;
      this->someArray = new int[this->arrayLength];
      for(int ind = 0; ind < this->arrayLength; ++ind) { this->someArray[ind] = rhs.someArray[ind]; }
      bResult = true;
    }
    return bResult;
  }
  // etc...
};


Now in a derived class, deep copying can be extended like so:


class Derived : public Base {
public:
  int someOtherValue;
protected:
  bool deepcopy(const Derived& rhs) {
    bool bResult = Base::deepcopy(rhs);
    if(bResult) {
      this->someOtherValue = rhs.someOtherValue;
    }
    return bResult;
  }
  // etc...
};


Of course the drawback of this technique is that every class in your hierarchy has to have a “deepcopy” method. However, it does save time when writing the assignment operator and copy constructors, since they rely on the deepcopy method and their function bodies become completely trivial.

3. Should copying an object cause any side effects to the original object?

This is a little trickier topic, since while the answer seems very obvious at first I’ve come across a scenario where it wasn’t the case. My example was when an object had sole responsibility or control over an external resource and I needed to transfer ownership to the new copy and remove ownership from the old copy. This means that copying an object has a side effect to the copied object on the right-hand-side of the assignment operator.

In this case, you will have to remove the keyword “const” from the deepcopy, copy constructor and assignment operator methods. You should also explicitly document what is going on when a copy is made as a client/user will assume (and rightfully so) that performing a copy will leave the right-hand-side copy unscathed.

Ideally you should avoid these scenarios altogether by redesigning your code in such a way that the right-hand-side object is not affected by the copy (Note that smart pointers may have helped me avoid this scenario).

I had been under the philosophy much earlier on to just “do what it takes” to accomplish something without heavy regard for good design, etc. I now have paid the price for that a few times, since as the code has evolved, I’ve had to redesign/refactor significant sections of code.

Anyway, I totally reworked the component hierarchy so graphical components of the user interface includes base Components with subclasses of Containers, Labels, Images. All of these components can be bound to event handlers at run-time for the following mouse events: “onMouseEnter”, “onMouseExit”, “onMouseMove”, “onMousePressed”, “onMouseReleased” and “onMouseClicked”. Each game state has a “desktop” container that contains the screen elements and components are added, initialized, positioned and sized and bound to events at run-time. Events are forwarded to the desktop container which handles routing the events down the hierarchy.

This is all pretty basic UI component hierarchy stuff, and I’ve done similar frameworks before (in DirectX, for instance). It’s a shame that I couldn’t reuse a lot of that stuff but it ends up being too specific (coordinate systems, pointers to surfaces, etc) that I end up re-inventing the wheel each time. I’ll write another entry in a few days about that as I’ve been reading and practicing UML and OCL at work. [Editor's Note: This never happened, sorry]

I guess I could have gone with one of the several GUI packages out there for SDL but this one sort of evolved from the current code and now I’m growing to like it.

Anyway, now that I have the basic UI component hierarchy in place, I’m going back into game code and start to implement the map rendering function that displays where the characters are in the school. One of my first tasks once this is complete is to allow the user to scroll the map in any direction by dragging the map with the middle mouse button.