Feeds:
Posts
Comments

Archive for October, 2012

As someone who’s interested in acquiring a job in programming in the near future, I recently came to the conclusion that I should probably create a few demo projects that can be sent in with job applications. As the industry is unlikely to be at the cutting edge of compilers, thanks to established code bases, and probably even less likely to be using the GCC compiler, I made a move over to Microsoft Visual Studio. To ensure the code worked, this meant a move away from all my C++11 code – the removal of smart pointers, the auto keyword, range based for loops, member initialization in header files and others.

To start this off I chose to work once again on my Brick Buster project, thinking that my knowledge of the code and it’s (relative) brevity would enable the process. The first thing to be removed was member initialization in header files, which meant a return to long constructor initialization lists. The move away from C++11 also meant losing delegating constructors, so I had to rewrite my Ball class. This actually helped clean the code up as I went from three to 2 constructors.

The next step was to remove all traces of smart pointers, a task that I thought would be arduous at best and fatal to stability at worst. In reality it was remarkably simple – I removed each smart pointer one at a time, compiling after each batch of changes to ensure that the code still worked. The only really tricky change came in the Game class where the currentState pointer had to be changed from a unique_ptr to a GameState*, which had a knock on effect for my FSM. In the end I decided to pass a reference to the currentState into the FSM, which would delete it and return a new GameState* which could be assigned to currentState:

currentState = FSM::changeState(currentState, player, imgCache, stateMan);

Of course the major fallout from the loss of smart pointers is memory management. Making sure that the correct delete call is placed everywhere it is required is not an easy task and led to my destructors increasing in size from nothing to multiple lines. To counteract the repetition of for loops containing delete and erase instructions for vectors, I wrote a template deleting function which will work with any container that has an iterator:

template <typename T>
void deletePtrCntr(T& cntr) const
{
    for(typename T::iterator it = cntr.begin(); it != cntr.end();)
    {
        delete *it;
        it = cntr.erase(it);
    }
}

Next step was the auto keyword. Now I love the auto keyword, it makes writing iterators infinitely quicker (4 chars vs 25+) and easier and allows the user of std::pair in a much nicer way. However, with the loss of C++11 they were written out and replaced by their verbose C++03 counterparts. As part of this removal, range based for loops disappeared from the code as well, rewritten back to the same standard as every other for loop.

One thing that almost got forgotten in the change over was enum classes. I have two of these in Brick Buster: one for the states and one for the power ups. The reason I use them is to give them their own type (instead of returning an int from a function, I can return a State or a GamePowerUp) and to keep the namespace pollution down (instead of calling my enum members STATE_TITLE, I can call them through State::Title or GamePowerUp::BigBall), both brilliant additions in my opinion. However if these were to be removed it would mean renaming the members to make it more obvious, or so I thought until I had the brainwave to put them inside their own namespaces so that they can still be called through State::Title or GamePowerUp::Multiball. Of course any function that previously returned a State or GamePowerUp had to be changed to return an int, but this was a minor change that caused almost no nuisance.

Of course as with all code rewrites, improvements are made to the codebase and it now looks a lot more organised. I’ve changed (back) to references from pointers in my base GameState class on the basis that none of the classes should ever be NULL as they are constructed before any GameState is ever created. This makes things slightly easier, removing the need for pointer dereferencing and -> everywhere.

To make the code portable, I put the SDL files inside the project and pointed the linker at the relevant folders so that anyone can compile the game on their computer if they have VS. This has given me the incentive and knowledge to go an rewrite my other games for VS and hopefully they won’t take to long to complete either.

The Brick Buster for MS VS10 is on the downloads page

Advertisements

Read Full Post »