The actual quote about c and C++ is most commonly attributed to Bjarne Stroustrup and it goes like this:

C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off (link)

git is not for faint hearted. Proper usage requires knowledge of branches, merging, remotes, detached heads (OK, maybe not detached heads, but I just wanted to mention those as they sound cool). Plenty a developer can go for years without ever having to branch (myself included). git, on the other hand almost mandates using local branches on daily basis.

History rewriting deserves a special chapter in the book of git-fu. The fetch-rebase-rebase workflow is ostensibly simple, yet incredibly powerful. This lead me to believe that git-rebase is a special kind of weapon – a handheld Tomahawk launcher with a twist.
If you do happen to shoot yourself in the foot, and by that stage you already took out half a suburb with you, it gives you an option to go back in time and prevent yourself from doing that. A bit like Nicholas Cage in the movie Next.

The only catch is that you get a second chance once, rewriting history is something that should only be on on un-pushed changes. Once you push those changes (and you get a safeguard from that git that will disallow pushing rewritten history without --force flag), all bets are off. I am not even sure what happens with other people’s repositories when a branch has been rebased upstream, most likely your coworkers will be highly pissed of with you.

Development managers have beards

Seriously. 100% of the dev managers that I’ve come across (a total of two) have beards. With that, I would like to conclude that all development managers have beards. Also, both of the ones I met happen to be really cool dudes, but that’s beside the point.

Having said that, I realise my failing to secure a development manager position. I didn’t have a beard. So, if you are on the market for dev manager position, you must have a beard.

It helps to be good

I really enjoyed going to the interviews and I thought I did alright at all of them. So much so, that I thought I could totally do it full time. At some point I realised that it’s not some weird skill that I happened to have, but that I was pretty good at what I do. Not totally awsome, which is the goal, but better than average.

Don’t take this the wrong way. If you are reading this post, I can pretty much guarantee that I am on par with you – just a normal programmer who is pretty passionate about what he does. I’ve met plenty of totally awsome devs in my time and I can tell you, I’d give an arm and leg to be half as awesome as them. It is pretty surprising, really, how little effort it takes to be above the average line in this business.

Karma is totally real

Being a fairly active StackOverflow participant, giving back to the community is fun. You get points and get to receive instant feedback from others if something that you say sucks. To most non-geek folk out there it’s virtually impossible to explain why you would selflessly spend so much of your time helping others.

But get this. After two months of constant applying and weeks of interviews, technical tests and take home assignments (which are totally what you’d get if you are going for senior developer positions), the one offer I got was through agent thrawling SO for people in the area that are active in a particular tag set.

Not by placing a job ad on careers.

Not by signing to search candidates on careers.

Just by brute forcing their way through participants. Kudos.

You have to work hard for it

Yeah. Applying for senior developer position in Sydney is hard work. The market for .NET developers is pretty lively at the moment, so I would recommend to only apply for the jobs that you are totally in love with.

ThoughtWorks, being the heavyweight of employment process, has the following approximate steps:

• HR quick interview
• Take home assignment (~2 days part time to complete)
• Logic and aptitude test
• Tech interview 1
• Tech interview 2
• Cultutal interview
• Management interview

Compared to the other places, they are not entirely unreasonable. Although the logic test at TW deserves a special mention as it’s so so so cool. You basically need to turn you brain into pointer dereferencing CPU for 45 minutes. I’ve never seen anything like it and a quick search online didn’t turn up a similar one.

Place 2

• Online test with the agency
• Technical questionaire
• Technical interview (this one was 3 hours)
• Take home assignment (about the same amount of effort as ThoughWorks)

Plase 3

• Online test
• Written test at the place
• Tech interview
• Cultural interview (with BeardDev 1)
• Cultural interview 2. I made it this far at which point they decided I was overqualified. It was annoying and I still don’t actually agree with them, but it turned out for the better.

Place 4 (the place)

• Take home written test
• Interview with architect and dev manager (BeardDev 2)
• Reference check
• Offer

So, be prepared. Luckily I liked all the tests, especially take home assignments. Wriating about writing those deserves a separate blog post, as there are nuances that caught me out. Publisising those will make for an interesting read.

Doing what you love, point 2

There is a parallel with what happened to me and what my wife is going through at the moment. She loves making parties (invites, themes, decorations, etc). She also loves facebook and not in the time wasting way. She communicates with other mums out there who have babies of similar ages to ours, which has been god sent for her.

By taking the two things shes loves and combining them, she is now on her way to creating a business – printaparty.com.au – designer party invites and themes you can print at home(the site is designed by her and humbly coded by yours truly). Genius. I have no doubt, she wouldn’t need to go back to full time work after maternity leave. Turns out facebook is unparalled in promoting an at home (mummy) business.

There something important here, and that is your participation in the community must be genuine. That much is obvious. You don’t want to be another loud mouth “guru” who jumps on whatever bandwagon is in to promote self. People are not dumb and they will see through that.

To wrap it up

I think it should become clear what the point of this post is. By being geniune and striving for the best, you are well on the way to happiness. This is a very Zen-like approach that seemed to have worked for me, I hope it does for you :)

That aside, I have discovered a feature in Unity container that makes implementing a composite pattern kinda fun. Just a brief remainder of what the composite pattern is. It is a simple pattern where a class implements an interface and delegates invocation on that interface to an internal collection of actual interface implementations. This allows the calling class to treat multiple implementations as one single component.

Generally, this pattern is most appropriate for interface containing methods that have a simple return type or void ( i.e. Command Pattern). I found that things that are called “SomethingPolicy” are a good match for this pattern. In this example I will use ASP .NET authorization as an example of how to create a true Open-Closed component using a composite pattern.

For the sake of clarity I will call the class implementing the composite pattern composite class and actual implementations implementation interfaces.

The implementation of this pattern relies on a couple of interesting Unity Container properties.

Property 1: Items registered with a name are not resolvable through Resolve(). Also remember that a Resolve() call is the same as taking a dependency on that type in the constructor. These registrations are only available when calling ResolveAll().

Property 2 Items registered without a name are not available when calling ResolveAll() and are only available as a result of a call to Resolve().

This means that you can register the composite class without a name and implementation interfaces as mappings with name. The composite class then becomes the default implementation – i.e. when someone takes a dependency on that interface in the constructor.

This question describes how to create a base controller that overrides OnAuthorization() method and allows to require authorization by default, without having to decorate all action methods with [Authorize] attribute.

So, here is the base controller:

public class BaseController : Controller
{
    private readonly IAuthorizationPolicy _Policy;

    public BaseController(IAuthorizationPolicy policy) {
      _Policy = policy;
    }
   
    protected override void OnAuthorization(AuthorizationContext filterContext)
    {
        // Check if this action has NotAuthorizeAttribute
        object[] attributes = filterContext.ActionDescriptor.GetCustomAttributes(true);
        if (attributes.Any(a => a is NotAuthorizeAttribute)) return;

        filterContext.Result = _Policy.Execute(filterContext);
    }
}

Below is the composite class. Note that it takes a constructor parameter of an array of mappings of implementation interface registration to the order in which it should be executed. This allows fine tuning the order in which the policies are executed. Note the near textbook following of SRP, where the logic of executing multiple policies and ordering of invocations is kept out of the controller class. The reason for this collection being an array of key value pairs as opposed to a dictionary is for ease of configuration through XML configuration.

    public interface IAuthorizationPolicy {
        ActionResult Execute(AuthorizationContext context);
    }

    public class AuthorizationPolicyComposite : IAuthorizationPolicy{
        
        private KeyValuePair<int, string>[] _NameList;
        private IEnumerable<IRequestPolicy> _Policies;

        /// <summary>
        /// Creates AuthorizationPolicyComposite class.
        /// </summary>
        /// <param name="dictionary">priority list of container registration names. E.g. {1,"policy1"} will use the container 
        /// to resolve an instance of <see cref="IAuthorizationPolicy"/> using "policy1" name and will put that instance in the order specified by the integer.</param>
        public AuthorizationPolicyComposite(KeyValuePair<string, int>[] dictionary) {
            // TODO: Complete member initialization
            this._NameList = dictionary;

            InitComposite();
        }

        private void InitComposite() {
            _Policies = _NameList
                .OrderBy(item => item.Value) //sort on order number
                .Select(item => _Container.Resolve<IAuthorizationPolicy>(item.Key));
        }

        #region IRequestPolicy Members

        public System.Web.Mvc.ActionResult Execute(AuthorizationContext context) {
            foreach(var policy in _Policies) {
                var result = policy.Execute(context);
                if(result != null)
                    return result;
            }
            return null;
        }
    }

The registrations for all of these can be done as follows:

private void InitContainer(IUnityContainer container) {
    //composite regisrtation
    container.RegisterType<IAuthorizationPolicy, AuthorizationPolicyComposite>(new Dictionary<string,int> {
        {"normal", 1},
        {"activation", 2},
    }.ToArray());
    //normal authorization policy
    container.RegisterType<IAuthorizationPolicy, NormalAuthorizationPolicy>("normal");
    //User activation authorization policy - i.e. a user must go through activation process on first login
    container.RegisterType<IAuthorizationPolicy, UserActivationAuthorizationPolicy>("activation");
}

That’s it. The configuration for XML is not included here as it is pretty much the same as the API version. There is a trick to get the KeyValuePairs to work using a converter, but that’s a topic for another post.

Bob C. Martin’s *Agile Principles, Patterns, and Practices in C#” has to be the most readable and enjoyable computer text ever written. Having created production object orientated code for years, seeing ways to do OO properly is eye opening. Reflecting back, I realise that a lot of that “OO” code is actually procedural code written using OO tools.

A lot of the patterns described in the book are really there to enforce one of the guiding principles – Single Responsibility Principle (SRP). By looking at designing your system through the SRP lens, a lot of things become clearer.

In OO classes are first class citizens, and as a C++ developer, having one method classes seemed like a waste. Sounds silly, but I thought that a class should have lots of methods in order for it to be useful. Having now opened the door to designing loosely coupled system with lots of coherent classes, there is no going back.

I think this should be one of the main tenets tought in OO classes – THERE IS NOTHING WRONG WITH SMALL CLASSES. “Saving” classes by bundling lots of functionality into them has to be eradicated early in OO education.

Back to the book. As I mentioned before, having C++ background made this book even more fun to read as I could tell that the code was originally written in C++. Most of the code is .NET 1.1 and that might be the only minor criticism – sample code does not have most of the new features of even .NET 2.0 (e.g. generics). I would also like to see what would happen if this book was rewritten to take into account functional aspects of .NET 3.5 – lambdas, LINQ libraries, Expressions.

Another valuable insight that I found particularly useful is working through the design to figure out if a pattern application is necessary. A lot of the time design patterns can become “golden hammers” of software teams, it’s good to know when to stop and evaluate if a pattern is needed.

Overall, this is a must read for any developer. C++, Java or C# people will all get something out of it.

Every now and then I wish this pattern can be used in C#. If you attempt to implement it C++ style, you would get a compile error:

    public abstract class Base<T> {
        public T FluentMethod() {
            return (T)(this); //error CS0030: Cannot convert type 'InheritanceTest.Base<T>' to 'T'
        }
    }

    public class Derived : Base<Derived> {
    }

This is probably a point at which you give up and find another way of doing things. It is, however, possible to implement a fully functioning curiously recurring class system in C# by simply adding a constraint to the base class like so:

    public abstract class Base<T> where T : Base<T>{
        public T FluentMethod() {
            return (T)(this); 
        }
    }

    public class Derived : Base<Derived> {
    }

If you attempt to read the constraint your brain will probably spin in infinite circles trying to figure out how it is even possible for a type parameter to be the same as the class itself. The fact that it works, however, is not more magic than the C++ version, where the recursive nature of the class declaration simply compiles. What the constraint really says is that T is a class that derives from Base, which is what Derived is.

Another observation. You cannot use Base<T> by itself. It must be inherited from. The abstract keyword is not compulsory, it will compile without it. You just won’t be able to declare an instance of Base<T> by itself.

This post joins a long list of posts that are inspired by one of my StackOverflow answers. The code that uses this pattern can be found in MVCContrib project.

The problem to be solved was creating a factory that would at runtime merge two implementations of different interfaces into one object. I have implemented this using Castle Dynamic Proxy (which is totally awesome, that’s why all mocking/testing libraries use it).

In this post I want to concentrate more on the performance aspects of the solution and provide source code for your own perusal. There are two implementations of CreateMixin – generic and non-generic versions. They are completely different in how they mix interfaces.

CreateMixin

The non-generic version simply leverages Castle Dynamic Proxy mixins to bundle objects into one instance. The downside is that all of those interfaces are implemented explicitly and the returned instance must be cast to each individual interface to be used. Here is the implementation and the unit test:

public static object CreateMixin(params object[] instances) {

    ProxyGenerator generator = new ProxyGenerator();
    ProxyGenerationOptions options = new ProxyGenerationOptions();

    instances.ToList().ForEach(obj => options.AddMixinInstance(obj));

    return generator.CreateClassProxy<object>(options);
}
[TestMethod]
public void CreatedMixinShouldntThrow() {
    ICat obj1 = new Cat();
    IDog obj2 = new Dog();

    var actual = Factory.CreateMixin(obj1, obj2);
    ((IDog)actual).Bark();
    var weight = ((IDog)actual).Weight;
    ((ICat)actual).Meow();
    var age = ((ICat)actual).Age;
}

CreateMixin<T>

While I was playing around with it I thought I’d create another factory method that could return a strongly typed version of the super object. This turned out to be tricky as this was a bit like having cake and eating it too.

The initial implementation was fairly slow in comparison to the native class implementation (i.e. fully implemented at compile time) – about a thousand times slower. The Castle DP mixin performance on the other hand was pretty good. The breakdown was something like this:

• Native ~10ms
• Mixin ~300ms
• Generic mixin ~10000ms

The culprit, as expected, was this bit of code. It uses reflection and is extremely slow compared to native or even Castle mixins.

    public void Intercept(IInvocation invocation) {
        invocation.ReturnValue = invocation.Method.Invoke(m_Instance, invocation.Arguments);
    }

After digging around Dynamic proxy code I have found IChangeProxyTarget interface that allows to change the target of invocation in the interceptor. Since we want to simply redirect a call from the combined interface to the implementation, all we need to do is point the invocation towards the actual instance.

public void Intercept(IInvocation invocation) {
    IChangeProxyTarget changeTarget = (IChangeProxyTarget)invocation;
    changeTarget.ChangeInvocationTarget(m_Target);
    invocation.Proceed();
}

The only icky bit about this is the fact that we need to call CreateInterfaceProxyWithTargetInterface in order to be able to switch target of invocation in the interceptor method. What this implies, however is that we need to provide an instance of the combined interface (which never gets used anyway), so we actually create another proxy and pass that to the proxy creation method. A bit recursive, but it gets the job done.

And here is the factory method with test:

public static TMixin CreateMixin<TMixin>(params object[] instances)
where TMixin : class {
    if(instances == null || instances.Length == 0 || instances.Any(o => o == null))
        throw new ArgumentException("All mixins should be non-null", "instances");

    ProxyGenerator generator = new ProxyGenerator();
    ProxyGenerationOptions options = new ProxyGenerationOptions();
    options.Selector = new MixinSelector();
    var dummy = generator.CreateInterfaceProxyWithoutTarget<TMixin>();

    return generator.CreateInterfaceProxyWithTargetInterface<TMixin>(dummy, options, instances.Select(o => new MixinInterceptor(o)).ToArray());
}
[TestMethod]
public void CreatedGeneric3MixinShouldntThrow() {
    ICat obj1 = new Cat();
    IDog obj2 = new Dog();
    IMouse obj3 = new Mouse();
    var actual = Factory.CreateMixin<ICatDogMouse>(obj1, obj2, obj3);

    actual.Bark();
    var weight = actual.Weight;
    actual.Meow();
    var age = actual.Age;
    actual.Squeek();
}

The result is that performance is improved by a lot:

• Native ~10ms
• Mixin ~300ms
• Generic mixin ~500ms

Oh and by the way, this is for 8M invocations. So it’s not that big of a hit in realistic terms. I wouldn’t run this in a very tight loop – e.g. image processing or anything real time but it’s quite suitable for calling some service every now and again.

MixinFactory Source

The advantage of rendering the Error view by calling ErrorController.Execute, as opposed to making an entry in web.config, is that you get to preserve the URL without a browser redirect.

If you think about which scenarios warrant a 404 response a more involved strategy is justifiable:

1. Non-supported controller name – captured by {controller}/{action}/{parameter} rule.
2. Supported controller but bad action – captured by Controller.HandleUnknownAction.
3. Non-supported URL format – captured by the catch-all rule.

Using ErrorController.Execute allows to preserve the URL for all of those scenarios. Now, to trap all unhandled exceptions in order to not show a Yellow Screen of Death, you would need to do some error handling in Application.Error event handler. Something similar is described in this answer.

There is a catch, however. If the anti-XSS features kick in and disallow a URL containing, say, angle brackets, executing error controller from global exception handler will throw an exception resulting in a YSOD.

The best solution i found was to catch the exception when doing Execute and do a browser redirect then. This prevents the runtime from creating a YSOD due to an unhandled exception in the exception event.

IController errorController = ControllerBuilder.Current.GetControllerFactory().CreateController(null, "error");
try {
    errorController.Execute(new RequestContext(
            contextBase, errorRoute));
} catch(Exception) {
    //If we are here it means that the URL is unsafe and the only way to handle it gracefully is to redirect.
    Response.Redirect("~/Error/BadRequest"); //Controller/View pair that returns 400 - Bad Request
}

It’s probably not the best idea to handle 400 error as 404, hence we redirect to a “BadRequest” action in the ErrorController.

Please note that this post is written in April 2010, when the WP7 SDK is only one month old. Most of the issues described here will likely not be a problem in later releases. The defining characteristic of such pre-release SDK is that when you are doing the right thing, everything is OK. When you screw up, it just goes KABOOM! without much explanation.

I spent a few hours of trying to work out why I am getting these run-time errors and so I’ve put together a list of the most painful ones, enjoy.

Using {x:Static ...} Syntax

Problem: {x:Static ...} is not supported in Silverlight.

If you to do something like this:

<DiscreteObjectKeyFrame  KeyTime="00:00:00" Value="{x:Static Visibility.Collapsed}">

You will get an obtuse error at runtime:

A first chance exception of type 'System.Windows.Markup.XamlParseException' occurred in System.Windows.dll
Additional information: 2024 An error has occurred. [Line: 114 Position: 61]

Get used to seeing that error. It’ll happen every time you screw up the XAML. Sometimes it’s more helpful than other times and you get the line number of the offending XAML. The line number, along with the exception text will be available in the Output window:

If you are like me and rarely look at the error window, perhaps you should start now. This particular error doesn’t raise a warning during compilation, but does come up as an error when the file is open in the editor:

Solution: Don’t use x:Static but instead an instance of a type in XAML like so:

    <DiscreteObjectKeyFrame  KeyTime="00:00:00">
        <DiscreteObjectKeyFrame.Value>
            <Visibility>Collapsed</Visibility>
        </DiscreteObjectKeyFrame.Value>
    </DiscreteObjectKeyFrame>

Misspelling Animation Element or Property Name

Problem: Misspelling Animation Element or Property Name

In the below code Storyboard.TargetName is invalid. The project compiles and there are no errors in the error window.

    <ObjectAnimationUsingKeyFrames Storyboard.TargetName="SearchBoxMisspelled" Storyboard.TargetProperty="Visibility">
        <!--animation key frames-->
    </ObjectAnimationUsingKeyFrames>

At run-time, you get this error message:

A first chance exception of type 'System.InvalidOperationException' occurred in System.Windows.dll
An unhandled exception of type 'System.InvalidOperationException' occurred in System.Windows.dll
Additional information: 2213 An error has occurred.

The call stack only tells you that this is something to do with the animation:

System.Windows.dll!MS.Internal.XcpImports.MethodEx(System.IntPtr ptr = 146517008, string name = "Begin", MS.Internal.CValue[] cvData = null) + 0x9d bytes
System.Windows.dll!MS.Internal.XcpImports.MethodEx(System.Windows.DependencyObject obj = {System.Windows.Media.Animation.Storyboard}, string name = "Begin") + 0x6 bytes

System.Windows.dll!MS.Internal.XcpImports.Storyboard_Begin(System.Windows.Media.Animation.Storyboard storyboard = {System.Windows.Media.Animation.Storyboard})
System.Windows.dll!System.Windows.Media.Animation.Storyboard.Begin() + 0x6 bytes

Solution: To resolve this, check your animation element and property names. Unfortunately I haven’t found a way to get at the offending animation frame from the call stack. Would be happy to find out if there is a way.

References’ Dependencies

Problem: “Object reference is not set to an instance of an object” error when debugging and crashes when running without debugger.

After adding a reference library you might start getting this error when you debug the project:

This is caused, as far as I can tell, by your references’ dependencies not being copied to the device. After hours of playing around with this it’s apparent to me that this is an intermittent issue with Visual Studio. It is supposed to work out what all the references’ dependencies are, copy them to the output folder and add them to the manifest file ($(OutputDir)\AppManifest.xaml).

Sometimes that doesn’t happen and the app gets deployed without those dependencies. It will still work, up until the point where a class is referenced from a dependant assembly and that assembly cannot be loaded. I expect this problem to go away in later releases of WP7 SDK.

The error will look something like this:

2024 An error has occurred[Line:  Position: ]
at
System.Windows.Application.LoadComponent
...Rest of the callstack.

Solution: Add all the assembiles that your references depend upon as references to the project. Edit: This error kept happening to me until my coworker pointed out the solution, which led to the “Doh moment of the week.” Solution2: When debugging the project select the project in the solution pane and press F5. Yeah, that simple.

I finally got it but it took a while. The issue, particularly in F#, is that combinators don’t make all that much sense as a substitute for non-recursive functions. After all, the only way to run the combinator recursively is with a recursive function (as in let rec). A different solution might be to use recursive types, but that’s is pretty pointless. There was a great StackOverflow question about that by the way.

What is a combinator

I am getting ahead of myself though. Combinators are a mathematical concept pioneered by Haskell Curry. The essence of combinators is that they allow sophisticated computation by combining simple functions. Hence the term combinator. Combinators allow a recursive algorithm to be written using a function that does not call itself but instead invokes another function that is passed in as one of the arguments.

One distinct characteristic of a combinator function is that all of its variables are bound. That means that the function only depends on its parameters, not any other data structures or function defined elsewhere. Just about the best description of what is a combinator and what isn’t can be found here

let freevar=3 //a variable

let IAmACombinator x = x*2;; //variable x is bound as a formal parameter
let IAmNotACombinator x = x*y;; x is bound but y is free. This is not a combinator

Example

Lets do some examples. An algorithm that I will implement is the sum of arithmetic progression. It’s an algorithm that can really be solved in O(1) time (by using the formula (m+n)*(m-n+1)/2, but it makes for good tail recursion test (i.e. you can blow the stack quite easily, unlike the factorial, which runs out of the integer range at about 15).

This is the normal recursive arithmetic progression function:

let rec progsum x =  
    if x <= 1 then 1 
    else x+progsum (x-1)

Combinator Version

Thanks to F# type inference, the combinator function is pretty the same for any application and only depends on the number of parameters to the worker function.

This is the combinator version of the above function:

//Normal arithmentic progression sum combinator
let rec comb f = f (fun x -> comb f x)
let progworker f x = 
    if x <= 1 then 1 
    else x+f(x-1)
//Use partial application to wrap up the combinator call    
let progCombinator x = comb progworker x ;;

This might need a bit of explaining. comb is a higher order function that takes another function as a parameter and returns a function taking one argument. This returned function is what we actually want – a function taking one parameter and returning something of the same type as the parameter.

In the above snippet progCombinator is a convenient way to partially apply our combinator to the arithmetic progression worker function. We could have just as easily done for a factorial:

let factworker f x = 
    if x <= 1 then 1
    else f(x-1) * x;;
//Use partial application to wrap up the combinator call    
let factCombinator x = comb factworker x ;;

Tail recursion

Tail Call Optimization is an F# compiler feature (and in some cases JIT Compiler feature) where it will transform a recursive function into a while loop if the recursive call is the last statement in the function. Let’s go back to the original arithmetic progression function and see if that is the case:

let rec progsum x =  
    if x <= 1 then 1 
    else x+progsum(x-1)

And it isn’t. Even though it looks like the function call is the last statement of the function, progsum(x+1) will be evaluated before x+progsum(x+1) can be computed. Let’s rewrite it to take advantage of tail recursion:

let progTR x =  
    let rec inner x sum = 
        if x <= 1 then sum 
        else inner (x-1) (sum + x)
    inner x 1;;

So, what happened here? Well, for once we declared a wrapper function and the worker function inside it. This is not strictly necessary, but allows to hide some of the implementation semantics. So, if we can visualize how the original function worked, this is a crude diagram that shows the execution path for x = 4:

progsum 4
->calls progsum 3
  ->calls progsum 2
    ->calls progsum 1
       ->returns 1
    <-returns (progsum 1) + 2
  <-returns (progsum 2) + 3
<-returns (progsum 3) + 4

As you can see the result is computed "on the way out" - i.e. as the function returns. In the tail recursive version we compute the result "on the way in", which allows the recursive function invocation to be the last statement in the function. Here is the diagram:

inner 4 1
->calls inner 3 (1 + 4)
  ->calls inner 2 (5 + 3)
    ->calls inner 1 (8 + 2)
      -> returns 10
    <-returns 10
  <-returns 10
<-returns 10

An interesting side effect of this tail recursive function is the fact that the order in which sum happens is not quite the same as in the original function.

Original:

4 + (3 + (2 +(1)))

Tail Recursive:

((4 + 1) + 3) + 2

Tail Recursive Combinator

So, now that we've gone over combinator functions and tail recursive functions you may ask: "What about tail recursive combinators? Do those exist?". And the answer would be "Yes, indeed, such beasts do exist". Here is the same algorithm implemented as a tail recursive combinator:

let rec combTR f = f (fun x acc -> combTR f x acc)
let progTR f x acc = 
    match x with
    | 1 -> acc
    | x -> f(x-1) (acc + x);;
    
let progCombTR x = combTR progTR x 1;;

Looking at the code, there is nothing groundbreaking there. Just as we converted the original function into a tail recursive function by adding a second parameter, we did the same for the both the combinator function and the inner function.

For more details on tail recursion and different ways to optimise it have a look here and here.

So the trick to get this working as pointed out in the article was to call the function on the pointer or reference of the parameter to the original function, thus cauising a second dispatch.

class A {
  virtual void PublicFunction(B& b) {
    b.PerformFunction(*this);
  }
}

The problem with doing this sort of thing with subclasses of the same base is that we need to allow the possibility of the base class being called with one of its subclasses as a parameter. Luckily we can use forward declarations to define the functions and implement them later on.

class b;
class c;
class a {
protected:
    virtual void doFoobar(a& a2); //do stuff here 
    virtual void doFoobar(b& b2); //delegate to b
    virtual void doFoobar(c& c2); //delegate to c
public:
    virtual void foobar(a& a2) {
        a2.doFoobar(*this);
    }
    friend class b;
    friend class c;
};
class b : public a {
protected:
    virtual void doFoobar(a& a2); //do stuff here 
    virtual void doFoobar(b& b2); //do stuff here
    virtual void doFoobar(c& c2); //delegate to c
public:
    virtual void foobar(a& a2) {
        a2.doFoobar(*this);
    }
    friend class a;
};
class c : public b {
protected:
    virtual void doFoobar(a& a2); //do stuff here 
    virtual void doFoobar(b& b2); //do stuff here
    virtual void doFoobar(c& c2); //delegate to c
public:
    virtual void foobar(a& a2) {
        a2.doFoobar(*this);
    }
    friend class a;
    friend class b;
};
//class a
void a::doFoobar(a& a2)  {
    printf("Doing a<->a\n");
}
void a::doFoobar(b& b2)  {
    b2.doFoobar(*this);
}
void a::doFoobar(c& c2)  {
    c2.doFoobar(*this);
}
//class b
void b::doFoobar(a& a2)  {
    printf("Doing b<->a\n");
}
void b::doFoobar(b& b2)  {
    printf("Doing b<->b\n");
}
void b::doFoobar(c& c2)  {
    c2.doFoobar(*this);
}
//class c
void c::doFoobar(a& a2)  {
    printf("Doing c<->a\n");
}
void c::doFoobar(b& b2)  {
    printf("Doing c<->b\n");
}
void c::doFoobar(c& c2)  {
    printf("Doing c<->c\n");
}

The code is far from an ideal double dispatch solution as it relies on the forward declaration trick to resolve the circular dependency between the subclasses. This means that all the classes that need to have this functionality must be known at compile-time (of the base class). This means the base class cannot be made into a library component.

To explain all the friend declarations. Considering the fact that all the classes a, b and c are tightly coupled as is, I added friend declarations so that the actual worker function is private and cannot be called from the outside.