Test Drum

14 05 2013

Since I’m working on two projects at the moment (both written in C#), and since both of them will end up as games (hopefully), I’ve decided I needed something else to wash away the taste of gameplay code and graphics code and physics code and whatever else kind of code a single game developer must write. So I’ve decided to write my own testing framework for C++! Why?! why not?!

Actually as far as the “why not” question goes I can give many reasons why not (and you, yes YOU, can probably give some more) but heck, this is my time and I want to try it. Let’s see how far I get into it before my eyes go cross 😛

As a first disclaimer I would like to say that I have already started this project a couple of times before just to test (hee hee, see what I did there) the water. As another disclaimer I would also like to mention that I’ve used and am using the wonderfully wonderful UnitTest++ and so am more than a little influenced by it. Having said that, “Test Drum” will not be a copy/paste affair but another approach to that same basic concept.

As I’ve mentioned just passing the framework’s name is ‘Test Drum’. Don’t ask me why since I’ve got no idea.

With that in mind let’s put down some ground rules;

Test Drum is designed to be a portable, lightweight
and fast framework for writing tests in C++

So, what’s a test?

A test [in the framework] is any function that contains
some expectations in it.

Next, what exactly is an expectation?

Expectations are code slices that test specific conditions
on input data; the expectation code should throw a
specialized exception (ExpectationFailed) if any of its
conditions are not met.

And finally the idea of the TestContext.

A TestContext is a mapping between a name and a 'Test' function.
A TestContext is executed in order to run its testing function.

I think that with these three basic ideas I can start writing the framework and later begin iteration and refinement. Already I know that I’m missing basic concepts such as timed tests, test fixtures and test suites. But those I’m happy to add on later once the groundwork is done.

This post is almost done but before I go I want set the corner stone of this framework. Namely, the actual test function, which is in fact nothing more than a function pointer.

typedef void (*Test)();

Well, that’s it for today.
“I may take a holiday in Spain, leave my wings behind me…”

Advertisements




Timer – Part 2

2 12 2010

Finally, Timers and all that Jazz. Let’s continue with a quick sneak peek into the previous post and the original requirements.

Another thing I would like to test is whether our timer is running or not.

TEST_FIXTURE(timer_not_running, _check_timer_is_not_running)
{
  CHECK_EQUAL(false, _timer.IsRunning());
}

Add the functionality and remove the duplication.

#ifndef _TDD_TIMER_
#define _TDD_TIMER_

class Timer
{
  public:
    typedef char* name_type;
    typedef double elapsed_type;

    bool IsRunning() const { return _isRunning; }
    name_type Name() const { return _name; }
    elapsed_type TotalElapsed() const { return _totalElapsed; }

    Timer(name_type name)
    : _name(name)
    , _totalElapsed(0)
    , _isRunning(false)
    {}

  private:
    bool _isRunning;
    name_type _name;
    elapsed_type _totalElapsed;
};

#endif/*_TDD_TIMER_*/

Compile, run, works, let’s stop for a moment and think. At the end of the last post I’ve had to make a design decision regarding the Timer and with the boolean test I’ve just written that decision comes into light. But what is it? The answer lies in the fixture itself. By allowing tests to be carried across a Timer object which is not running I’ve actually also stated that the Timer object will have to be started manually by the class users. It may seem to be a small part of the overall design and probably fairly intuitive and/or obvious but we also have to remember that this functionality emerged as a consequence of writing the tests first. Another benefit of these tests which can become apparent is their value as documentation. With just a glance at the name of this fixture we are already shown what can and needs to be done in order to use our Timer.

There’s one last thing I can think of that the Timer needs at the moment and that’s the ability to measure the time elapsed between updates. A timer that hasn’t been started and hasn’t updated should report that value as zero though.

TEST_FIXTURE(timer_not_running, _check_tick_elapsed_is_zero)
{
  CHECK_EQUAL(0, _timer.TickElapsed());
}

And we know the drill by now so let’s just skip and create the property and variable in the same step.

#ifndef _TDD_TIMER_
#define _TDD_TIMER_

class Timer
{
  public:
    typedef char* name_type;
    typedef double elapsed_type;

    bool IsRunning() const { return _isRunning; }    
    name_type Name() const { return _name; }    
    elapsed_type TickElapsed() const { return _tickElapsed; }    
    elapsed_type TotalElapsed() const { return _totalElapsed; }

    Timer(name_type name)
    : _isRunning(false)
    , _name(name)
    , _tickElapsed(0)
    , _totalElapsed(0)
    {}

  private:
    bool _isRunning;
    name_type _name;
    elapsed_type _tickElapsed;
    elapsed_type _totalElapsed;
};

#endif/*_TDD_TIMER_*/

Run the tests, see that everything works. And that’s all the functionality I can think of that our non-running timer should or can expose for us. We need to step it up, go crazy… Let’s make a timer that actually runs!

#include <UnitTests.h>
#include "Timer.h"

struct timer_is_running
{
  Timer::name_type _name;
  Timer _timer;

 ~timer_is_running(){}
   timer_is_running()
   : _name("IsRunning")
   , _timer(_name)
   {}
};

TEST_FIXTURE(timer_is_running, _check_timer_name_is_correct)
{
  CHECK_EQUAL(_name, _timer.Name());
}

Run tests and everything is green. Now comes a little confession. I’m not sure whether I should re-test the name functionality which is immutable in the sense that the name cannot change and has already been proven to be working properly by removing the code duplication from the previous tests. For now I’ll keep the test and the test-code duplication it [sort of] brings, why? I’m not sure…

Let’s look at the running timer concept. I know that the fixture as it stands will not start a timer running because the previous test for IsRunning() passes on false. My assumption though is that the IsRunning() on a running timer should be true. Test time.

TEST_FIXTURE(timer_running, _check_is_running)
{
  CHECK_EQUAL(true, _timer.IsRunning());
}

Run and fail. Clearly we need a way to start the timer and change the value returned by IsRunning(). Unlike the previous tests I can’t just hardcode a return true since the other test will fail. I’ve got to actually add a function to do that and call it before I test, to do this I’ll modify the fixture a bit.

#include <UnitTests.h>
#include "Timer.h"

struct timer_is_running
{
  Timer::name_type _name;
  Timer _timer;

 ~timer_is_running(){}
   timer_is_running()
   : _name("IsRunning")
   , _timer(_name)
   {
      _timer.Start();
   }
};

Compile, run… Hey, it’s not even compiling now; apparently we need to actually write the Start() function.

#ifndef _TDD_TIMER_
#define _TDD_TIMER_

#include <cassert>

class Timer
{
  public:
    typedef char* name_type;
    typedef double elapsed_type;

    bool IsRunning() const { return _isRunning; }    
    name_type Name() const { return _name; }    
    elapsed_type TickElapsed() const { return _tickElapsed; }    
    elapsed_type TotalElapsed() const { return _totalElapsed; }

    void Start();

    Timer(name_type name)
    : _isRunning(false)
    , _name(name)
    , _tickElapsed(0)
    , _totalElapsed(0)
    {}

  private:
    bool _isRunning;
    name_type _name;
    elapsed_type _tickElapsed;
    elapsed_type _totalElapsed;
};

inline void Timer::Start()
{
  assert(_isRunning==false);
  _isRunning=true;
}

#endif/*_TDD_TIMER_*/

I’ve jumped a step in there by already putting in the code to change the _isRunning variable because there’s no point in trying to run the tests for running’s sake. I’ve also added an assert there [I’ll assume anyone who reads this also read my other posts about preconditions/postconditions and writing custom asserts]. The assert is another preliminary test to communicate the internal logic of the Timer. In this case I’ve chosen to say that trying to Start a running timer is cause for alarm because somewhere there’s a logic misstep. Anyway, compile, run, test and pass.

This post is running a bit long and I’m running a bit tired but I’m happy with the direction this is taking…

“I pounded on a farmhouse looking for a place to stay, I was mighty mighty tired I had come a long long way”





Timer – Part 1

27 11 2010

Why part 1? Because arrays are zero-indexed for me.
Lame jokes aside, let’s continue… um… now what?

In the army when we’ve done navigation field exercises they told us that whenever we get confused or lost the best option is to find higher grounds and survey the land. This particular advice is just as relevent for me here as it was back then [although no matter how many times I got up I always got lost again on the way down but that’s another story :D].

The equivalent to taking to the higher grounds here is looking back at the original answer to “what do I want?”. Ok, looked at it, now what’s the simplest state in which a Timer object can exist? The simple answer [and simple is the only answer one should look for when testing first] is a Timer that isn’t running. Sounds good, let’s do that. I can already see that I’m going to end up with some duplicated setup code so I’ll write the fixture code now [but keep the previous test in a different file, call this one timer_not_running_tests.cpp].

#include <UnitTests.h>
#include "Timer.h"

struct timer_not_running
{
  Timer::name_type _name;
   Timer _timer;

 ~timer_not_running(){}
    timer_not_running()
    : _name("NotRunning")
    , _timer(_name)
    {}
};

TEST_FIXTURE(timer_not_running, _check_timer_name_is_correct)
{
  CHECK_EQUAL(_name, _timer.Name());
}

Compile, run and watch it flame. Why? Timer::Name() returns a constant string to satisfy the previous test. Stop, let’s reflect here for a second before going on. If we look at the code from last post we’ll also notice that the first test we wrote suffers from a bad case of code duplication. The “Timer1” string is constantly duplicated, in the test and in the Timer class code. I’m going to take the time now to remove the duplication by refactoring the Name() function.

#ifndef _TDD_TIMER_
#define _TDD_TIMER_

class Timer
{
  public:
    typedef char* name_type;

    name_type Name() const { return _name; }

    Timer(name_type name)
    : _name(name)
    {}

  private:
    name_type _name;
};

#endif/*_TDD_TIMER_*/

Compile, run and watch both tests pass. What have I learnt? Removing code duplication as soon as possible leads to more general solutions. So from now on, obvious code duplication should be removed as soon as possible. The second test should always be written though, to verify that the solution is indeed what we want. The other approach for something like this is using the additional tests to force the functionality to change, in this case I would have had to hold the name string in an actual variable in order to have different names. Using more tests to zoom-in on the correct implementation is called Triangulation within the Agile circles and I usually use it to flesh out complex functionality. Alright, less talk more code, I’m testing a timer that isn’t running. If a timer isn’t running then the total time that it counted should be zero, right? let’s test.

TEST_FIXTURE(timer_not_running, _check_total_elapsed_time_is_zero)
{
  CHECK_EQUAL(0, _timer.TotalElapsed());
}

Compile, run, things explode, let’s add the right function.

#ifndef _TDD_TIMER_
#define _TDD_TIMER_

class Timer
{
  public:
    typedef char* name_type;
    typedef double elapsed_type;

    name_type Name() const { return _name; }
    elapsed_type TotalElapsed() const { return 0; }

    Timer(name_type name)
    : _name(name)
    {}

  private:
    name_type _name;
};

#endif/*_TDD_TIMER_*/

Whoops, code duplication. Let’s refactor.

#ifndef _TDD_TIMER_
#define _TDD_TIMER_

class Timer
{
  public:
    typedef char* name_type;
    typedef double elapsed_type;

    name_type Name() const { return _name; }
    elapsed_type TotalElapsed() const { return _totalElapsed; }

    Timer(name_type name)
    : _name(name)
    , _totalElapsed(0)
    {}

  private:
    name_type _name;
    elapsed_type _totalElapsed;
};

#endif/*_TDD_TIMER_*/

Compile, run, all tests pass and I’m happy. The code itself isn’t very exciting to look at, after all of this and I’ve just got two functions up and running. But the bigger picture is a bit more invloved. I’ve learnt the importance of removing code duplication early, I’ve had some more practice in making assumptions about functionality [a timer counts the total elapsed time therefore a timer that isn’t running should have a zero value for it]. And last but far from least, I’ve started documenting the contract between the client [what is needed] and the developer [what the code does] through the tests; that is, the timer must have a name and will measure a total amount of elapsed time. There is one more design decision I’ve made here, it might not be as obvious though, can anyone spot what it is??

“…Into the half light, Another velvet morning for me, yeah…”





Need…More..Time

26 11 2010

What a hectic, horrible week… Sometimes life throws a curve ball that hits you square in the, well, soft bits…
But enough bad sport-to-life metaphors; let’s get on with some code. Been writing alot of C# lately and I’ve got lots of stuff to say about the language [and most of it is even good believe it or not] but right now I’d like to take the time to go through the motion of TDD and my Timer class and all in glorious C++, yay!

For my main testing framework I use UnitTest++ which is simple to use and robust testing framework by Noel Llopis and Charles Nicholson. The only hickups I’ve had with it so far are the ++ in the namespace name and the fact that the TEST_FIXTURE macro seems to generate an intellisense error on odd numbers of tests [which is most likely a problem with the intellisense on my copy of Visual Studio 2010 Express rather than the actual code].

Most of the time when I’m about to test or design something the first question I usually ask myself is, what do I want?
So, in short, I want a class that will be able to act as a timer and measure both its total running time and the elapsed time between two ticks [handy for frame timing]. Like a good stopwatch it should also be able to stop, start and reset when needed.

Ok, I know what I want, let’s see what I can get. In a glance I can also see that as far as a full component the Timer isn’t going to be overly complex so I most definitly can finish writing it up it a while and a little bit… But because I’m not sure where all the bits are going to go and the whole point is to practice TDD I’m going to test first and see what happens.

Everything set, everything go. First test.

#include <UnitTest.h>
#include "Timer.h"

TEST(check_timer_name_is_timer1)
{
  Timer timer("timer1");
  CHECK_EQUAL("timer1", timer.Name());
}

Stop, compile, and watch it crash. So many things don’t even exist yet. Before I continue though, most developers I worked with would probably laugh at the level of functionality I’ve just tested. The arguments I usually hear are: It’s too small, it’s testing that the language work and it’s such a small thing it’ll only take a second to write. And to that I usually answer, there’s nothing too small to test because you never know what you might change. Also, I’m not actually testing functionality, I’m designing it. And finally, if it only takes a second to write it’ll only take a second to test and surely it’s better to have a test then not have one.

Now what?
Well, the compiler tells me that I don’t have a file called “timer.h”; so let’s create one.
Now the compiler complains that there’s no such thing as a Timer class. Quick, let’s write one up.

#ifndef _TDD_TIMER_
#define _TDD_TIMER_

class Timer
{

};

#endif/*_TDD_TIMER_*/

Compile, run, more complaints… What a fussy environment. The constructor signature doesn’t match and there’s no function called Name().

#ifndef _TDD_TIMER_
#define _TDD_TIMER_

class Timer
{
  public:
    typedef char* name_type;
    
    name_type Name() const { return "timer1"; }

    Timer(name_type name){}
};

#endif/*_TDD_TIMER_*/

Compile, run and phew… The test passes. The first functionality is in. It doesn’t look like much but the important thing is that it follows the design decisions as documented via the tests. I think this process is far too long for any single post and I’ll run it over the next few days [one post per day] until I get a timer or a headache, depends.

“…and if I bring a little music I can fit right in…”





Fake enums

26 10 2010

The more I write ActionScript code the more I want to write C++ code. Partially because I like C++ and partially because I dislike ActionScript I guess. In many ways, and probably a whole topic in and of itself, the enjoyment and usage of a programming language is highly subjective. But it isn’t the topic of this post.

ActionScript 3.0 doesn’t support the notion of built-in enumerated values. Otherwise known as enums by those with a panache for shortening words. The thing about enums is that, well, they are really really useful to have around when we want to limit the input range of a given function or container. Enums give us an even further advantage though in the sense that they not only provide a controlling mechanism but also an associative relationship between a symbol and its representation in the system. A simple example in C++.

enum StateType
{
  IN_GAME = 0,
  IN_MENU = 1,
  IN_TRANSITION_OUT = 2,
  IN_TRANSITION_IN = 3,
};

In this case we can define another variable in the main game class which holds a current state [not the best solution but a simple and viable one nonetheless].

StateType mCurrentState = StateType::IN_MENU;

mCurrentState can now only hold those values specified by the StateType enum. And not only that but each particular value has a meaningful name. Very useful and, unfortunetly, non-existant in ActionScript 3.0. So I finally gave up and decided to hack something together. It’s a bit ungainly as a solution but it’s a neccessary evil for now.

The other tactic one can employ in this situation, by the way, is to simply create a few static constants and pass them around as unsigned/signed integers. Good but not quite what I want although it is a part of my solution. This Type class is designed to define a few buttons on the main menu and make sure we can’t accidently choose a funny button.

public class ButtonType
{
  public static const BUTTON_01:uint = 0;
  public static const BUTTON_02:uint = 1;
  public static const BUTTON_03:uint = 2;
  public static const BUTTON_04:uint = 3;

  public static function CheckValid(_value:uint):void
  {
    switch (_value)
    {
      case SHARK_ISLAND:
      case SEVEN_CITIES:
      case UNKNOWN_BOOK:
      case INSTRUCTIONS: break;
      default: { throw Error("Unrecognized button type"); }
    }
  }  
  public function get value():uint { return mValue; }
  public function set value(_value:uint):void
  {
    CheckValid(_value);
    mValue = _value;
  }
	
  public function ButtonType(_type:uint)
  { 
    this.value = _type;
  }

  /*PRIVATE DATA*/
  private var mValue:uint = 0;
}

Why go through all the trouble of writing a different class instead of just encoding the static constants into the main menu class? My reasons are as follow:

  1. Because it means the MainMenu will have one less responsiblity to take care of [validity check].
  2. Code is now localized. So all code changes to button types [adding/removing types] and their validity checking would only occur in one place.
  3. Other classes which only use the button types don’t need to have knowledge of the entire MainMenu class [ie. import it]

Any better ideas out there?

“And every time she sneezes I believe it’s love and, oh lord, I’m not ready for this sort of thing…”





Some ado for things to do

23 10 2010

In a complete change of pace from the last few posts I’d like to go back to some C++ mainly because, well, I missed writing C++ code. [I haven’t finished the RunningCore but I’ll post up the complete code later and I’m sure no one would mind].

I’ve recently had a couple of conversations with people who have just started programming and I’ve seen code posted by other people who are going through the process and all of it reminded me of my first forays into the C++ language and the way we were taught it at school. The following are just some things I picked up on the way, they are my opinion of course and anyone can and probably will disagree with some of them if not all of them. Please feel free to comment [editing this I just realized it’s a pun, you’ll understand later] since I’m always up to learning new things and/or unlearning bad habits which is usually alot harder. So, without further ado, let’s start.

using namespace std;

This line is present in almost every tutorial or book I’ve seen and used by every teacher I met, all for the sake of brevity of code. Well guess what, the scoping operator is in the language to be used. C++ supports namespaces for a reason and it’s best to get students used to the fact that code is separated logically into ‘spaces. Exposing everything in a namespace like that will trample on other people’s code and cause annoying name clashes. If a function has too many ‘::’ in it for your liking the better alternative is to use a using directive local to that function.

int main(int argc, char* argv[])
{
  using std::cout;
  using std::endl;

  cout<<"Hello World!"<<endl;
}

Keeping with the namespace theme, put your code [yes I’m talking to you!] in your own namespace. The global namespace is full of things as it is, don’t add more to the party. Be proud of your code, own it. The global namespace will thank you and so would anyone coming after you that uses your code but also wants to have another function called Create() which does something completely different.

And another thing, comments are NOT your friend!
No, seriously, if someone tells you to document everything with comments then shoot them. Documenting algorithms should be in the documentation not in between the code lines. Comments are not meant for documentation purposes. They are also not used for this purpose:

void function()
{
  int i=0;
  int a=12;
  i+=a;
  //i-=a*2; <------ This is NOT a good practice
}

If you comment a line, delete it, otherwise it’s flotsam, rubbish in the code stream. If you want to branch out from a particular codebase or just revert to some old code then use your VCS [Version Control System]. What, you aren’t using one! Stop writing code, just stop and go get one. Doesn’t matter if it’s Git, Mercurial, SVN or whatever. Your code is too precious to be left hanging without a VCS. And no, for the love of the gods [you know, Zeus, or Odin, or who ever you happen to believe in] DropBox IS NOT A VCS. If you ask around the office what kind of VCS they’re using and they tell you DropBox, RUN!

Hm… Where was I?
Documents, yeah. Coding standards are good, they’re good to have around and they’re good to document. I submitted a 6 page review in college for the coding standards our team was suppose to follow. I got a really good mark for it. I should have failed. Coding standards are only good if people follow them and people will only follow them if they can
A. Read them in a glance and,
B. Actually retain the rules in their head.

6 pages of documentation just for that allows for neither. Having globalized standards is important to any project but if they sit on more than 1 A4 page of 1.5 line-space, 12pt Ariel font then it’s a waste of time. Think hard about what’s important to you; items like, perhaps, Directory structure, Tabs vs. Spaces and indentation rules. A character count for global/local/static variables is useless [I had it in my particular document example and I wish I didn’t].

And just a few more for the road before I leave.
Braces, unlike commets, are your friends. They love you and they love us. They show everyone where everything lives and which lines belong to which if.

if (condition) { doSoemthing(); }
if (anotherCondition)
{
  doSomething2();
  doSomething3();
}

switch (lastCondition)
{
  case 0: { doSomething(); break; }
  case 1: { doSomething2(); break; }
  case 2:
  {
    doSomething3();
    dontDoAnything();
    break;
  }
  deafult: { handleDefault(); }
};

Clean and clear code can save lives you know, mostly yours if the maintainer has access to your address.
Get into good coding practices from the start. Don’t be fooled by tutorials or teachers telling you that it doesn’t matter. It does. And it’ll make life easier in the long run [just not the short one].

And one last, tiny little thing. If you have to include windows.h do it in a .cpp file, in a different directory on some else’s computer through a DLL. Worst header ever written…

“I think I’m a banana tree, Oh dear, I’m going slightly mad”





MacroMagic

30 08 2010

So, the past couple of posts have been about error handling, reporting and what-not. There were also mentioned a few macros here and there. To conclude this saga I’d like to make this post about the #define magic; or black magic if you will.

Let’s preface this entire discussion with what I’d like to call, my precondition to the PRECONDITION. I’m not a great proponent of macros. In fact I try to avoid the preprocessor as much as I can [for reasons which are discussed pretty much everywhere concerning C and/or C++ programming]. That said though I don’t actually subscribe to the notion that a #define is evil. Like many things in my development environment the preprocessor is a tool, bit blunt, bit dangerous, but a tool nonetheless. Guns don’t kill people, code-maintainers do; in frustration. But let’s get back to the macro faeries.

The first iteration of my macro implementation went fairly close to the normal assert. For two very good references about asserting I’d like to point to the following, Game Programming Gems and http://cnicholson.net/2009/02/stupid-c-tricks-adventures-in-assert/ which doesn’t seem to show in my browser so I don’t know if it’s still there or not?

Ok, enough talking, let’s code; this is what the #define looked in practice.
PRECONDITION(mCreated==true, "window has not been created yet");

Seems alright on the surface but the first question I’ve had for it was whether the condition should be met or not. That is, am I saying:
if (condition) { report message; }or
if (not condition) { report message; }

One might be inclined to simply look at the PRECONDITION code and derive conclusions from there but I think functionality should be understandable through use of code, not inspection [which is why I haven’t posted up the code yet]; so I’ve changed the code to look like this;
PRECONDITION(mCreated==false,/*otherwise*/"window has not been created yet");

Better in the sense that it now clarifies the intent but it still rubs me the wrong way since I’ve had to resort to a comment [which is external to code]. In response I’ve done someting which I’m still not sure is a good idea but I’m keeping at the moment. I’ve separated the PRECONDITION macro into two interrelated and interconnected macros;
PRECONDITION(mCreated==true) OTHERWISE_REPORT("this window has not been created yet");

It’s not an ideal solution, in fact it’s blunt and ugly [although ugly here is good since it tells me it’s a macro], but I’m satisfied with it at the moment. The main reason I have for using a macro rather than a function call is the need to report file, function and line location of the call as well as provide a breakpoint into the code at the appropriate place for a trace.

The Postcondition, as you may have already guessed looks pretty much the same. I value code coherency very much, if I write one type of interface I keep the rest of the related types with the same interface.
POSTCONDITION(mCreated==false) OTHERWISE_THROW("could not create window");

And as for the actual PRECONDITION and POSTCONDITION code;
#ifndef _FORGE_ERROR_POSTCONDITION_
#define _FORGE_ERROR_POSTCONDITION_

#include <sstream>
#include <exception>

#define POSTCONDITION(condition)  \
do        \
{ \
  if (!(condition)) \
  { \
    std::ostringstream os; \
    os <<'\n'<<"** POSTCONDITION FAILED **"\
       <<'\n'<<"CONDITION : "<<#condition \
       <<'\n'<<"FILE : "<<__FILE__ \
       <<'\n'<<"LINE : "<<__LINE__ \
       <<'\n'<<"FUNCTION : "<<__FUNCTION__
#define OTHERWISE_THROW(name, message) \
       <<'\n'<<"NAME : "<<name \
       <<'\n'<<"MESSAGE : "<<message<<'\n'; \
       throw std::range_error(os.str().c_str()); \
  } \
}while(0)

#endif/*_FORGE_ERROR_POSTCONDITION_*/

#ifndef _FORGE_ERROR_PRECONDITION_
#define _FORGE_ERROR_PRECONDITION_

#include <iostream>

#ifndef UNIT_TEST_MODE
  #define BREAKPOINT_AND_ABORT __debugbreak(); std::abort()
#else
  #define BREAKPOINT_AND_ABORT
#endif/*UNIT_TEST_MODE*/

#ifndef DISABLE_FORGE_ASSERT
#define PRECONDITION(condition)        \
do                \
{ \
  if (!(condition)) \
  { \
    std::clog \
    <<'\n'<<"** PRECONDITION FAILED **" \
    <<'\n'<<"CONDITION: "<<#condition \
    <<'\n'<<"FILE : "<<__FILE__ \
    <<'\n'<<"LINE : "<<__LINE__ \
    <<'\n'<<"FUNCTION : "<<__FUNCTION__
#define OTHERWISE_REPORT(name, message) \
    <<'\n'<<"NAME : "<<name \
    <<'\n'<<"MESSAGE : "<<message \
    <<'\n'; \
    BREAKPOINT_AND_ABORT; \
  } \
}while(0)
#else
#define PRECONDITION(condition) do{ sizeof(condition);
#define OTHERWISE_REPORT(message) }while(0)

#endif/*DISABLE_FORGE_ASSERT*/

#endif/*_FORGE_ERROR_PRECONDITION_*/

Bit of a hack, but I’ve done worst. I’ve also been toying around with trying to move the PRECONDITION assert to compile time, or at least link time by using templates. I’ve not had much success yet, but I like templates so I’ll see if I can come up with something. Anyways, dishes await. Strange, seems like every time I need to do the dishes I try to post something before, coincidence? or black magic??

Hey Joe, where you goin’ with that gun in your hand?”