Another good reason to keep source file sizes small

Merging a file between SCM branches that is several thousand lines in size and has significant changes in both branches is a good way to have an unpleasant day, even if the SCM that’s being used has good support for cross-branch merging.

Yes, I know, ideally one tries to make sure that two branches don’t diverge that far but that’s not always possible, especially if there are significant changes to the design that affect the merge.

Useful collection of Qt debug visualizers for Visual Studio

I had to reinstall VS2010 at work and because I clearly didn’t think this all the way through, forgot to save my autoexp.dat file before removing the old installation. And of course I didn’t realise what had happened until I had to dig deeper into some Qt GUI code that wasn’t quite working as expected, and of course I was prompted with the raw data.

Fortunately a quick search on Google led me to this page Human Machine Teaming Lab | Knowledge / Qt that contains a very comprehensive set of visualisers. I’d highly recommend them if you’re doing any sort of work with the Qt libraries. Just keep in mind that the Qt visualisers are for Visual Studio 2008 and 2010, so they’re anything but guaranteed to work with newer versions.

Visual Studio 2010 SP1 has been released

For those who are using Visual Studio 2010, the service pack has now been officially released:

Visual Studio 2010 Service Pack 1 General Availability – Visual C++ Team Blog – Site Home – MSDN Blogs

Edit: The download like doesn’t seem to work for me yet, given that it’s only gone General Availability today it might be worth checking back a little later.

Edit again – we have a general availability download link:

If your VS2010 C++ build is constantly rebuilding a project that hasn’t changed…

Check if you’re seeing the following output in the build pane:

  Creating ".unsuccessfulbuild" because "AlwaysCreate" was specified.

I’ve just fixed a bunch of these errors in one of our solutions here and all of these were caused by one of two issues:

  • The project file referenced files that were no present in the source tree
  • A custom build step either was supposed to generate a file but didn’t, or the file ended up in the wrong place

In order to find out if there are missing files that trigger the perma-rebuild, you’ll also have to enable Visual Studio’s debug output as described in this stackoverflow answer.

How to view undecorated DLL-exported C++ symbols in Visual Studio 2010

Yes, it’s one of those “note to self” posts, but I keep forgetting how to do it.

As the first step, you run dumpbin /EXPORTS and redirect the output into a file because the utility that unmangles the names (undname.exe) doesn’t appear to be able to take piped input via stdin. Then, run undname <filename>, with <filename> being the file that contains the exported symbols.

At least that way the symbols become mostly readable.