I’ve been watching Bartosz Milewski’s C++ 11 Concurrency videos and they’re a pretty good way to get up to speed on the new threading support in the latest C++ standard. They start off nice and slowly, for people who haven’t been doing concurrency for years, and explain the various new features provided by the language. It’s good stuff.
I’ve been reading Anthony Williams’ C++ Concurrency In action which is a great way to understand the details of what you’ll see in the videos.
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.
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.
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).
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.
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.
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.
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.
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.
Undefined behaviour can be part of your contract with the client, you expect them to adhere to their side of the contract and if they do then you will keep your side; if they don’t then all bets are off.
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.
