When I heard that the theme for the Linden Lab Christmas party was going to be steam punk, I knew I had to go as Babbage Linden. Since 2005 my avatar in Second Life has sported a victorian suit from Neverland and a steam arm, originally from a Steambot avatar which I updated to a more recent design from Marcos Fonzerelli after Joe Linden started washing his face in my sink.

I had a suit that was close enough and a bit of riffling through local shops and ebay got me a waistcoat and cravat that were a pretty good match, but I knew the arm was going to need a lot of construction, even if I went for the first version from the Steambot. After some Googling trying to find out how to construct a conical frustum I remembered the export to world project that had converted Second Life objects to paper craft models. So, after checking that Marcos didn’t mind me exporting his geometry from Second Life, I decided to do that.

Installing OGLE proved to be really easy — just dragging the replacement OpenGL DLL and supplied config to the Second Life directory worked fine, but my first few captured scenes were full of unwanted clutter. In the end I found that using the advanced menu to turn off all render types apart from Basic, Volume and Bump and the UI feature allowed me to capture just the steambot arm placed in front of me in Second Life.

After opening the .obj file captured by OGLE in Blender, exporting it as a DXF and opening it in Pepakura Designer it was clear that the model was far too complicated — the cones and spheres created dozens of faces. Going back in to Second Life I broke the steambot arm in to 1 piece for each cardboard part I expected to make, stripped off all of the spheres, made the finger tips in to boxes instead of cones and then used the Second Life preferences to set the object mesh complexity to minimum, which reduced the number of faces on each cylinder to 6.

With these simplifications made the models looked much more managable when opened in Pepakura Designer, but it was still worth playing with open faces to simplify the parts in to quad strips. With these tweaks made I determined the correct scale. I placed my forearm on a couple of sheets of A4 and then adjusted the scale in Pepakura Designer until the steambot arm covered approximately the same amount of paper, then noted down the scale so I could use it when printing each part.

After printing the parts out on A4, I pinned them to some think double ply corrugated card from some old Dell boxes and then cut out the shapes and assembled them with gaffa tape, PVA and paper fasteners. I replaced the spheres with some polystyrene spheres from a craft shop and replaced the shiny with half a dozen coats of copperchrome spray paint.

I had a load of fun and the finished arm is amazingly sturdy, surviving 6 hours of Christmas party relatively unscathed. Who knows, maybe I’ll get another chance to wear it at an SLCC in the future. A full set of pictures with notes is available here.

The core of m0cxx0r is the creation of an object that records method calls and compares them to expectations. This is done by using C++ placement new to create a VTableDonor object in allocated memory the same size as the object being mocked and then returning the memory as a m0cxx0r::Mock class which inherits from T, the class of the object being mocked.

When methods are called on the mock object instead of invoking the methods in T, the virtual methods in VTableDonor are called instead and are able to record the calls made and compare them to expectations. The problem is that the signature of the original method and the VTableDonor method may not match.

In order to be able to find and compare parameters the VTableDonor methods take a single parameter which they can use as a fix point to find other parameters that may be passed to the call via pointer arithmetic. Luckily the rules for parameter layout are fairly simple, so if you know the address of the first parameter, it’s easy to find the others.

Unfortunately the same isn’t true for return values. Depending on the return type, space for the return value might be pushed on to the stack as a hidden parameter, a pointer to a heap location might be pushed or the caller may expect the return to be saved in a register. The rules for which mechanism is used depends on some combination of the compiler, platform and sometimes which C++ features the return type uses. To make matters worse the this pointer is also pushed as a hidden parameter which can become corrupted when there is a return type mismatch. All of this makes it very difficult to call a VTableDonor virtual method with a void return type in place of a virtual method on T with a non-void return type and have everything work correctly. You can see why people generally use the much simpler C ABI to nail binaries together.

After a lot of research and some trial and error I’ve managed to get m0cxx0r working with virtual methods returning primitive types and non-POD types by value in Visual Studio 2005 on Windows and using g++ 3.3 on Linux. The new code can be found here. I’m still having trouble getting it working on g++ 4.0.1 on Darwin where dyld seems to be noticing my monkeying around, causing the process to exit with a dyldmisaligned_stack_error — hopefully it will be possible to work around.

A potentially better solution is used by mockitopp, a brand new dynamic mock framework for C++ that I found on my travels around the internet today. Where m0cxx0r uses a compiler generated VTableDonor class and then attempts to work around the signature mismatch problems, mockitopp builds the mock vtable at run time which has the advantage that the entries can be made to match the signatures in the class being mocked. It looks to be a promising approach and I’m looking forward to investigating mockitopp further.