Geek Speak

Here’s a useful matrix which shows when each version of Visual Studio will become unsupported by Microsoft. I’m posting the link here as I’m sure I’ll not be able to find it the next time I need it…

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).

One of the problems of having a collection of tools that interoperate is that there’s often a lag between when a tool will interoperate with the latest version of another tool. I’m hardly a bleeding-edge tool junky, I wait until RTM before I start using the latest Visual Studio on a daily basis, and in the case of VC 6 I stuck with it (as did most of my clients) until VS2005 came out and actually improved life for unmanaged C++ development… However, it seems that some tools take a long long time to catch up with Visual Studio.

Yesterday I had a bug report from a client who had a user that was getting an exception report from their software which simply said “GetTempPath() - Failed to get temp path”. Now as error messages go this isn’t the best but it comes from some code that has been in my tools libraries for around 10 years and which has never failed before, it has no tests, we’re probably lucky that the message didn’t just read “TODO” as I’m pretty sure that it’s the first time that anyone has ever seen it apart from by reading my source code or running strings on an exe that includes my source code… Anyway…

I’m finding that the thread contention notation that I made up the other day to help me talk about the performance implications of the changes I was making is pretty useful. The definition needs adjusting slightly though… For a given lock the worst case contention is C. For an operation involving a single lock where t threads exist during the lifetime of the process and n threads access the lock the contention for the lock can be expressed as being C(n).

I have been updating some client code to VS2010 and they use STLPort for the STL as it has better performance in multi-threaded situations than the version that comes with Visual Studio (see here). This has meant that I’ve needed to build STLPort 5.2.1 with VS2010 for x86 and x64. As with my previous builds of STLPort the compiler isn’t currently officially supported so I had to hack my installation to get it all to build, etc.

This is a handy tip from Jim Beveridge. It shows you how to add to the list of native function calls that the debugger steps over rather than into when you’re debugging in various flavours of Visual Studio. I wonder if the debugger picks up changes to the registry key whilst VS is running, if so there’s scope to build a little add-in that lets you add to the list from within VS…

Today I had a day which I knew from the start would be broken up due to pre-arranged calls and meetings out of the office, and so I decided to deal with a few low importance items on my “todo” list. One of them was to do a proof of concept for a new tool that I might work on. I had a thoroughly enjoyable time hacking an old tool into shape so that I could use some of the technology in the new tool.

I’ve complained about DevPartner Studio enough in the past (here, here, here, etc.) that I thought I should write a positive blog posting since my recent experiences have been very positive. Some time ago I reported a bug in the BoundsChecker part of the product which meant that it hung sometimes in multi-threaded code. I managed to get a reasonably straight forward reproduction and raised an issue with them. It took a while but this is now fixed in 9.