This post first appeared on my old C++ blog. You might have seen it before.

I think by now we can all agree that exceptions are generally a good thing in C++. They allow us to separate the error handling from the general flow of control inside a program and also enable us to handle errors at the most appropriate point. More often than not, the best point to handle errors is quite far removed from the source of the exception.

These are just a couple of notes for some neat tips and tricks I’ve discovered over the years when using Boost.Test. They may not be all that useful to everybody else but they’re the ones I tend to forget about and then end up rediscovering. I’m using most of these with recent versions of Boost and these were tested with 1.54.

• You can nest test suites. I don’t use this feature and was surprised to discover it, but it makes a lot of sense if you’re dealing with large test suites that can be easily broken down into smaller logical chunks.
• If you arrange the tests in test suites (which you should anyway), you can run a single test suite by using -run_test=TestSuite. You can also run a single test inside a test suit or a nested suit by giving the appropriate path to -run_test, like so -run_test=TestSuite/TestName
• Fixtures are normal C++ structs/classes so you can derive from them to create more specialized fixtures. For example, in a set of test suite used to test a fairly large set of COM APIs, I use a single fixture to initialize COM, then derive fixtures to set up the tests for each interface. This cuts down a lot on duplicated initialization code.
• Boost.Test supports fixtures. Make lots of use of them to set up the environment for each of your tests instead of dumping a lot of the initialization code into each test case, which makes the test cases smaller, easier to read and you can follow the “let the first call in your test be the function you’re testing” mantra.
• Members of the fixtures can be used directly in your unit tests
• You can use BOOST_CHECK/BOOST_REQUIRE macros in the fixtures as well, although I would advise to make fairly minimal use of that. It does help if you are trying to test what I call “flaky” pieces of code.

Quick hack/warning for those using an alternative command line processor like TCC and also use Xoreax’ Incredibuild for distributed builds. Incredibuild is awesome, by the way, and if you have a larger C++ project that takes a long time to build, you should use it. And no, I’m not getting paid or receive free stuff for writing that.

However, if you have to start your Visual Studio instance from the command line because you need to set some environment variables first, or because of your general awesomeness, make sure you’re starting it from a stock Windows shell. Either the standard Windows command line (cmd.exe) or PowerShell will do nicely, thank you. If you start VS from TCC and have a couple of build tasks that spawn out to the shell, Incredibuild wants to shell out into TCC to run these tasks and the shelled out task don’t seem to return control to Incredibuild again. Yes, I was too lazy to investigate further as the method described above works.

I recently came across a discussion on LinkedIn where someone had run into memory related undefined behaviour. This prompted me to write this post as it’s a common, subtle and often not very well understood bug that’s easily introduced into C++ code.

Before we start, please keep in mind that what we’re talking about here is undefined behaviour in any standardized version of C++. You’re not guaranteed to see this behaviour in your particular environment and pretty much anything might happen, including your cat hitting the power button on your computer.

As VS2012’s C++ compiler doesn’t support “true” variadic templates, the new runtime library classes that use variadic templates are implemented using macro magic behind the scenes. In order to get the “variadic” templates to accept more than the default of five parameters, you’ll have to set _VARIADIC_MAX to the desired maximum number of parameters (between five and ten).

For more information, see the “faux variadics” section of this blog post on MSDN.

I’ve finally corrected some of the mistakes that I published in my blog post about the misuse of using namespace xxx. My apologies for taking this long.

Enjoy!

I was profiling some code a while ago that makes extensive use of boost::variant and one of the lessons from the profiler run was that boost variants appear to be fairly expensive to construct and copy.

As of 1.53, variants support rvalue constructors and rvalue assignment operators. My initial measurements suggest that when used with types that are “move enabled”, there is a benefit in upgrading to this version of boost variant, both in performance and memory consumption.

There, I’ve said it. No tiptoeing around.

As a senior developer/team lead, I get involved in hiring new team members and in certain cases also help out other teams with interviewing people. As part of the interview process, candidates are usually asked to write code, so I review a lot of code submissions. One trend I noticed with recent C++ code submissions is that the first like I encounter in any header file is

After all the brouhaha over Visual Studio 2012 not being able to build executables for Windows XP, it looks like Microsoft has reconsidered:

http://blogs.msdn.com/b/vcblog/archive/2012/06/15/10320645.aspx

Pity that we’ll have to wait for the update but at least those of us who still have clients that are exclusively XP can use a modern compiler…

… make sure that you have removed all dependencies on the project that you are about to remove before you remove the project from the solution.

If you don’t, the projects that still have dependencies on the project you just removed will retain the dependencies, but the dependencies will have become invisible and the only way to rid yourself of the “phantom dependencies” is by editing the actual vxcproj files with a text editor and remove the dependency entry in there manually.