7867.2

Being the cumulative mileage at the end of the month -- 255.7 miles for the month despite the damp patch in the second week of the month; 2275 (2707) miles ytd total and just under 1200 miles on the current chain (which is getting close to needing replacement).

So 3000 miles total for the year looks easy, but 3000 on my bike (or even 8500 on the clock) would require keeping up that rate all year, which isn't on with the clocks going in under 4 weeks.

C++ enum.toString() and then some -- or "preprocessor metaprogramming is like, 'wow!', man"

So I have a simple enough problem. I have a series of named data objects

and a container class

where there are COUNT of these items, each with a name, type and default value, and the Initialise method where heap allocations are done outside the constructor -- it simply fills in the array with appropriately typed named values with their default values, and I want client code to be able to index the array with symbolic names.

Plain enums don't have a to-string (though there are tricks to auto-associate names with strings by simple preprocessor metaprogramming); to get a compile-time count there's the old stand-by of putting an extra dummy member at the end and a big fat comment about inserting new values above it.

C++11 enum classes don't give me anything over the older enums here. There are various enum-like classes out there, in varying degrees of complexity; these give type-safety (which I don't really need in this context), could be extended with extra data, can be iterated over -- but don't give a compile-time count.

Time to break out Boost for some industrial grade tooling, and be very glad that my compiler supports variadic macros.

I want to define my items one time, one place, no extras like

Let's start with basing our enum representation off the Boost MPL wrapper for size_t

with static initialization

and from there it's just a case of using the preprocessor metaprogramming to put the bits together, just iterating over the definitions to define all the types, their static initialization and the array initialization:

Then in the Items.h header file where I defined D and Items, realise the common parts:

and the Items.cpp file realises the initialisations

and consumers have a tolerable symbolic constant access to the values

while extending the list only has to happen in one place.

I'm just not sure if it's a bit too magic for the purpose.

Five finger exercise -- a more complex cmdlet in C++/CLI

Moving on from the previous post, porting the main cmdlet example to C++/CLI -- along with adapting it to later PowerShell behaviour (the original code assumed that the provider path resolution would not throw on non-existent items, so some exception handling needed to be added ahead of the fallback check for the file existing), making it pass the MSFT FxCop rules for PowerShell (fixing the verb, class and namespace in the main), and allowing it to be localized (through resource files as well as through the PowerShell look-up mechanism), and so forth...

I let Visual Studio generate the class outline, so there's a slightly pointless split into header file and implementation, but that aside, it's only the little bits of baroque syntax that really distinguish it from the C# equivalent. So perhaps I shouldn't forget about the language quite so much.

Five finger exercise -- simple cmdlet in C++/CLI

I tend to forget that there are other .net languages than F# (oh, and the one that pays my salary); in particular, after some traumatic encounters with the original Managed C++, that C++/CLI is there and isn't too bad, especially when significant native interop is required (where even F#'s P/Invoke starts to drown in attributes). But for hardcore managed stuff...?

So I've been playing with some native code again, and was thinking to surface the functionality in PowerShell, since GUI programming is pretty tedious (I've set projects aside for half a year or more when the next step is to include a tree view control). So my first thought was to do that in F#, as I did that ages ago, back when you needed snap-ins and there were glitches in how F# compiled against that particular object inheritance tree.

But then, I thought, there's no need to be so polyglot, even if C++/CLI is a bit like Geordie when compared to Standard C++'s RP. So, to practice with the somewhat distractingly different keyword placement, here's the very first example from the old (and out of print) Wrox book

and, yes, snap-ins are old-tech, but they provide examples of how to override property definitions (in the simplest form, without mapping names). This has also been tweaked to be FxCop clean, including for the MSFT powershell rules.

Of course this was the point where I discovered that C++/CLI in VS2010 will only target .net 4, and I was writing this on my old Vista laptop, without space for back-version installs, and had to use the old familiar hack. But, that aside, it all went through most gratifyingly.

Next, to port one of the real examples, to see what other joy is involved.

.net under the covers — using/Using/use

Something I had occasion to look at the other day was exactly how the auto-disposal mechanism actually works for the out of the box .net languages: and there are some interesting quirks to be found. Take the equivalent sample code fragments

and for completeness, C++/CLI stack based disposal

All languages and configurations render this as a try {} finally { Dispose() } construction (apart from stack-based C++/CLI semantics, which generates a try {} catch { Dispose(); throw;} Dispose()), but there are devils in the details. In release mode, C# and VB compile to the same IL -- just dispose if the used value is not null

whereas F# compiles to

which is unexpected, as the compiler enforces the subject of a use initialisation to be an IDisposable anyway -- but, importantly, it does not test for null on the original reference.

In debug mode, all three languages differ, C# flips the test around

VB does something a bit more like F#

and F# just adds one of its usual bursts of gratuitous branching in the middle

The C++/CLI code can rely on the stack-based object not being null, so eschews any checks

Harvest Home

The last of the plums have been gathered in, and the freezer isn't quite bursting at the seams. The peak of the crop came a couple of weeks after the usual Bank Holiday weekend date, showing how the late spring has affected things. OTOH, the fruit were all on the large size, with few of the thumb-size specimens that usually form the last vestiges of the crop.

Should.BeAvailableInF#

Since I first heard of it, I've found the Should Assertions library convenient for the driver programs that stand in for more formal unit tests for code fragments that I want to blog. However, such main programs have to be written in C#, because you can't access C# extension methods on generic open types from F# -- which is exactly what the general run of Should extensions are.

So, you could write F# code like

but that is pretty ugly. And F# type extensions are defined against a specific class, so won't be any use. Which leaves us with generic functions as the best way to wrap the C# extension methods, but

isn't much of an improvement.

The approach that brings us closer to the C# feel would be to make these methods infix operators.

In an ideal world, we'd use ⊦ (U+22A6 ASSERTION) as a lead character, but that's not yet available without forking the compiler, so I chose to write the functions in the form |-{op}, doubling the first character of the {op} for the versions that take custom comparison objects, adding a trailing % for variants taking a message, and using !- as an introducer for unary operations like !-/, where / alludes to ∅ (U+2205 EMPTY SET) for ShouldBeNull.

Apart from the object/generic assertion, the other type that needs transformation across the language barrier is the ShouldThrow<T> extension on Action, which can be wrapped as a generic function taking a unit -> unit, which uses that to create a delegate for the C# world.

Putting it all together we have module fhould, a pun on f for F# and for the old-fashioned cursive long 's' as in ſhould:

Note that there is no order checking in the range tuples (they are just passed as (low, high) to the corresponding arguments of the underlying code); and that 3-ary methods (custom comparers or message strings) have to be invoked in one or other of these styles to get the association correct

and F# syntax doesn't permit us to define unary/generic ShouldBeType or ShouldImplement operators in the style of (!-@)<'a>.

Season's end

By the start of this month, the sunrise is late enough that even though it's clear daylight when the alarm goes off, the sun has yet to clear the house across the road and stream into the bedroom. In the evening, we've lost two hours daylight since the peak, in terms of how long it stays light enough to read sitting outdoors on a clear evening.

It was a good summer

At the start of the season, the TWO forecast was

The TWO summer forecast covering June, July and August has been issued and the headline is for a mixed summer with the best weather probably during the first half, with a deterioration later on. August is expected to bring the worst weather, but on the whole the summer isn't likely to be as bad as last year's.

which was upset by the heatwave in July -- even the August Bank Holiday weekend was mostly fine.

There was rain on the Thursday before, when we took Karen's mum out to lunch at the Willow Tree in Bourn, but it was fine when we returned there on Sunday afternoon for their barbecue garden party. While there, some of the players from the production of the Dream at Burwash Manor turned up in costume after the matinee, handing out flyers.

So we went to the Tuesday evening performance on a beautiful clear evening that only just started to feel cool after the stars were well out; and despite a forecast of cloud, Wednesday when we went to Orford for lunch at the Crown and Castle was almost cloudless, and lovely weather for sitting out on the terrace for lunch.

Thursday did the same for my long bike ride, then again of Friday for an afternoon at Linton Zoo, as did Saturday. Only today did it stay rather hazy.

As a result of the weather, with Karen being rather washed out by the heat, I did a lot more about house and garden, than I expected, getting around to bits of tidying that had needed doing since we got the adaptations done in '06 (the last time we had a semi-decent summer) and more miles on my bike at 100 miles a week -- including a lot of simple shopping runs.

OTOH, there are things I didn't do as a result -- code much, cook very much (when salads were often the order of the day), upgrade my phone or my home network, do anything shocking like get a tattoo.

But what I did accomplish was to shed a lot of stress, and decide that yes, I will be able to handle retirement if I can ever afford it. The lowered stress levels may last me until all of Tuesday, but it's still a decade until I can get my bus pass.