Boost Unit Test Reporting

In case it’s not obvious, I’m doing some work with boost today upgrading from 1.34.1 -> 1.42.0. I just came across this following error while running my tests

<pre>C:\projects\svn\bdk\ot51>ZenithBase_test.exe –report_level=yes
Test setup error: invalid report level yes</pre>

Thats funny because ‘yes’ used to be a valid option and I can’t see what they’ve changed it to or even what the possible options are anywhere on the internet… so I decided to put them down here based on my digging through the source:

* confirm – CONFIRMATION_REPORT,
* short – SHORT_REPORT,
* detailed – DETAILED_REPORT,
* no – NO_REPORT

BOOST_STATIC_ASSERT incomplete type not allowed

I’ve recently been trying to compile the newest boost library (1.42.0) using the Intel 11.0 compiler and came across this error in code which previously compiled using 1.34.1

1>../../deps/boost_1_42_0/boost/test/floating_point_comparison.hpp(229): error: incomplete type is not allowed
1>          BOOST_STATIC_ASSERT( !is_integral::value );
1>          ^
1>          detected during:
1>            instantiation of "boost::test_tools::predicate_result boost::test_tools::check_is_close_t::operator()(FPT1, FPT2, boost::test_tools::percent_tolerance_t, boost::test_tools::floating_point_comparison_type) const [with FPT1=int, FPT2=int, ToleranceBaseType=double]" at line 523 of "../../deps/boost_1_42_0/boost/test/test_tools.hpp"
1>            instantiation of "bool boost::test_tools::tt_detail::check_frwd(Pred, const boost::unit_test::lazy_ostream &, boost::test_tools::const_string, size_t={unsigned int}, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, const Arg0 &, const char *, const Arg1 &, const char *, const Arg2 &, const char *) [with Pred=boost::test_tools::check_is_close_t, Arg0=int, Arg1=int, Arg2=boost::test_tools::percent_tolerance_t]" at line 26 of
1>                      "..\tests\Timing\VlcTimingProfile_test.cpp"

incomplete type huh, what the hell could that be about? Well it turns out that this is just a very *un*informative error which is generated when the assert evaluated to false. In my case it was caused by calling BOOST_CHECK_CLOSE(int,int,float), when I changed this to BOOST_CHECK_CLOSE(float,float,float) it compiled fine… but the error message didn’t really reflect where the error was at all.

Boost tokenize for the win

String manipulation has historically been a major shortfalling of the C++ language, or at least it was until boost came along. Something as simple as spliting a string up on a delimeter is now made so much easier thanks to the boost::tokenizer and boost string algorithms.

#include <iostream>
#include <string>
#include <boost/foreach.hpp>
#include <boost/tokenizer.hpp>

using namespace std;
using namespace boost;

int main(int argc, char** argv)
{
   string text = "token, test   string";

   char_separator<char> sep(", ");
   tokenizer<char_separator<char>> tokens(text, sep);
   for (tokenizer<char_separator<char> >::iterator it = tokens.begin(); it != tokens.end(); ++it)
   {
      cout << *it << "." << endl;
   }
}

And my personal favourite is to push the result of the tokenization into a vector/list/stl container.

#include 
#include 
#include 
#include 
#include 

using namespace std;
using namespace boost;

int main(int argc, char** argv)
{
   string text = "token, test   string";

   list tokenList;
   split(tokenList, text, is_any_of(", "), token_compress_on);
   (list::iterator it = tokenList.begin(); it != tokenList.end(); ++it)
   {
      cout << *it << "." << endl;
   }
}

So awesome!

Stolen from the lazy programmer and reposted here for my own reference.

Visual Studio excluding exceptions

I was having a bit of a problem with Visual Studio and some code that I was working with, the author had used exceptions as a flow control mechanism for a properties object. If the object did not have a value for a given key it would throw an exception which he would then catch and replace with a default value. This led to some pain when I was looking to catch exceptions in the main body of code. If I turned c++ runtime exception catching on

Debug -> Exceptions -> C++ Exceptions

then it would give a pop up [break/continue/ignore] for each time this particular mechanism was called. Many many button clicks before getting to the main problem. Then a co-worker put me on to the following. Open up the c++ exceptions branch and click the add button, add the exception that you would like excluded, then when it pops up untick it. Simple!

Why use ++i instead of i++?

I knew that it was better practice to specify my for loops in c++ in the following form


for (int i=0; i<max_ITER; ++i)....


rather than


for (int i=0; i<max_ITER; i++)....


but I was unsure exactly why. The reason is that the post-fix operator requires three steps
1) a copy of the current value of i is made
2) the current value of i is incremented
3) the copy is returned

Obviously this isn’t a very big performance hit for simple integers but for more complicated classes where the pre/post fix operators are overloaded the second step may be a non-negligible stage and in a case such as the above for-loop counter where the value isn’t being used it is an unnecessary stage. Hence it is better practice to always use the ++i form of the increment unless the value is actually being used.