I have a tendency to write unit tests that are a little more invasive than they need to be; these tests make sure that not only are the results as expected but also that as many of the side-effects and interactions with other objects are as expected as well. So, for example, in my current WebSockets development for The Server Framework I have some tests which test that the correct data is delivered to the client of the API that I'm developing and also test that the API interacts with its buffer allocator correctly and doesn't leak memory. The…

Rather than immediately dive into the fun of writing my own invasive alternative for std::map I decided to take a look at what has been done before, as expected boost contains something that might work in the shape of the "intrusive containers library". Of course, being part of boost I first have to work out exactly how much more of boost it will require me to depend on and then I have to work out how I can use it to replace my current std::map usage. It seems quite clever (no surprise there) and allows for a type to be…

As I mentioned a while ago, I have some code which needs to perform better than it currently does and one of the areas that could be improved upon is the amount of contention for the heap that's occurring. The fact that I'm using an STL map for my collection means that the class has a 'big C' contention value of C(n threads using the heap) rather than C(n threads using the object). Of course, the fact that allocations need to be done at all is an unfortunate feature of std::map but rather than immediately replace the container with an…

I stumbled on an idea for speeding up C++ builds the other day and it's not something that I've considered before and it really does offer a considerable speed up so I think it may be worth considering in some situations. It has downsides which make it harder to use with my default style of code structuring but the increase in build speed is tempting... The idea is that of "Unity builds" which I discovered from an answer by Christoph Heindl on Stack Overflow about how to speed up Visual Studio builds. Christoph refers to this blog entry; The Magic…

I'm still skiing in Argentina, the training is going well and within 3 weeks I'll know if I make the grade and qualify as a BASI Ski Instructor... Because of all the skiing and partying and work out here I haven't been keeping up with many technical issues but this morning I checked bloglines and picked a couple of random feeds to catch up on. One of them was the Artima C++ Source feed which has recently published 5 articles by Scott Meyers. These articles are five lists of five of the "Best C++ ... ever", one on books, one…

In the fight to make C++ code easier to reason about and understand, never underestimate the value of a name. Giving something a decent name is the first step in thinking about the concept at a slightly more abstract level. Abstraction is all about selective forgetfulness, by grouping together several related program elements, defining a concept and giving that concept a name you can, from then on, choose to work at the level of the name rather than the detail. This has a marvellous effect on the amount of information that you can hold in your head at the same…

Another extremely powerful tool that you can use to ensure that your C++ code communicates as clearly as possible is const. By correctly using const all the time when designing your abstractions you can divide an object's interface into two smaller, easier to understand interfaces; one which does change the object's internal state and one which doesn't. By correctly using const all the time when defining constants and variables you can clearly communicate which are which. Strive to be const correct.…

When designing code it's often easy to include undefined behaviour. The need for code that exhibits this kind of behaviour is, however, generally pretty rare and there are often ways around allowing undefined behaviour. In general it's usually best to try to avoid undefined behaviour and instead be clear about exactly what happens under all usage conditions.…

One of my main aims when writing code in C++ is to have the code clearly communicate its purpose. I find it useful to be able to look at a single line in isolation and have a pretty good idea of what its effects are on the code that it cooperates with. Unfortunately C++ code can often be written in an imprecise way that makes reasoning about what it actually does harder than it needs to be. By increasing the precision of your code writing you can limit what the code could potentially do to just what you want it…