Never fear, boost is here!

I don't think I provided the link before to the Boost library, but here it is: http://www.boost.org.

I successfully used the unit test framework to test the initial version of the config file system for Block Drop. It was a cinch to setup and get running. With the test framework working, I should have more confidence to get new features out. Although, I am curious about how I am going use the unit test framework to test some of the graphics related systems. I am also wondering if there is a decent mocking toolset for C++. This would definately be a big plus so I can test the communication between the system interfaces. Looks like it is time to do more research.

Anyways, the config system was a breeze to get going. It is built ontop of the boost::program_options library. Boost does all the hard work. It provides all of the parsing/storing functionality in just two step:

1.) Define the option-value type pairs
2.) Parse the values from the config file

Here is a simple example of using the boost::program_options library.

...

#include 
namespace po = boost::program_options;

po::options_description description("Config File Options");
description.add_options()
   ("myOption", po::value<int>()->default_value(5), "My type of option")
   ("mySecondOption", po::value<std::vector<std::string>>(), "My second type of option")
   ;

po::variables_map map;
po::store(po::parse_config_file("configFile.cfg", description), map);
po::notify(map);

And that is all there is to it for loading the contents of a config file. Then whenever you need a specific value you just reference it through the map like this: map["myOption"].as(). The overloaded () operator makes it a breeze for organizing and adding options to the the list to be parsed.

The Monkeyboy Framework wraps this interface into its Configuration class which is meant to overriden by any system that uses the framework so that each new application can define its own configuration file and option-value pairs.

So Block Drop has a class called BlockDropConfiguration that inherits from the Monkeyboy Framework Configuration class. Here is how it defines its configuration file and option-value pairs:

BlockDropConfiguration::BlockDropConfiguration()
   : Configuration(std::string("blockDrop.cfg"))
{
   this->optionsDescription.add_options()
       ("title", po::value<std::string>(), "Title of the application")
       ("width", po::value<int>()->default_value(800), "Width of the application window")
       ("height", po::value<int>()->default_value(600), "Height of the application window")
   ;
}

Now the main Block Drop class owns an instance of the BlockDropConfiguration class and uses it to initialize its subsystems. Here is a sneek peek at it initializing the graphics subsystem.

...

class BlockDrop : GameDemoApplication
{
   BlockDrop::BlockDrop() {
       configuration.parse();
       configuration.loadGraphicsProperties(graphicsSystem);

       ... //Add more subsystem initialization calls
   }

   ...

private:
   BlockDropConfiguration configuration;
   Graphics graphicsSystem;
};

I decided on this approach since the configuration class is specific to the application so it should know what the graphics system needs to be initialized. I figured at the time of creation this appeared the be the easiest approach. I am open to input on this as well if anyone has any thoughts on a different approach.

OOH OOH EEH EEH

Boost Library Unit Test Framework

Alright, I know I have been away for a long while, but I'm back. And once again, so is Block Drop. This has been a project of mine that has been in development for a long time. It has experienced numerous architecture and platform changes. Mostly because of my interests changing so frequently. But that's okay, because it gives me a reason to learn something new.

Since we employ XP practices at work, I wanted to encorporate some of those practices to my Block Drop project. The first I intend to use is Test Driven Development (TDD). My first task was to find a good unit testing framework for C++. I narrowed the search down to CPPUnit and the boost::unit_test_framework. Both appeared to lack the ease of use as some of the Java test frameworks, but they seemed the easiest to get going and work with from my perspective.

I am thinking I will choose the boost library version because I intend to use the other features the boost library offers (i.e. smart_pointers, program_options, and possibly others). This will also bring the number of included libraries down.

OOH OOH EEH EEH