So, this is the deal:

• I’ll walk my way (slowly) through the new features that interest me the most, using the VS11 implementation of C++11.
• I’ll divide my journey into small-ish pieces that are easy enough to also blog about.
• I’ll take lots of detours into neighboring areas as I create supporting infrastructure to accomplish what I want and need.
• I’ll create “something real” without using any off-the-shelf libraries or tools, because I want to be self-sufficient using C++11, good old general C++ and a large portion of what I consider best practices.

Provided that VS11 supports these items, this is what I want to look closer at:

• Rvalue references and move constructors
• Type inference: auto, decltype
• Range-based for-loop
• Lambda functions
• Explicit overrides
• Null pointer constant
• Strongly typed enumerations
• Explicitly defaulted and deleted special member functions
• Static assertions
• Multithreading: std::thread, std::mutex, std::recursive_mutex, std::condition_variable, std::condition_variable_any, std::lock_guard, std::unique_lock, std::async, std::packaged_task, std::future, std::promise
• Hash sets: std::unordered_set, std::unordered_multiset, std::unordered_map, std::unordered_multimap
• Smart pointers: std::unique_ptr​, ​std::shared_ptr, std::weak_ptr​
• Extensible random number facility: 3 generators and a number of distributions

Where applicable, I will also look at the features from a performance perspective, what magic the compiler manages to pull off and what differences we’ll get at an assembly level by choosing to do this instead of that.

class custom_iterator : public std::iterator<std::input_iterator_tag, exposed_type>
{
public:

    custom_iterator(something_that_initializes_the_type_exposer& initializer)
        : exposer_(initializer)
    {
    }

    reference operator*()
    {
        return exposer_.ref();
    }

    const reference operator*() const
    {
        return exposer_.ref();
    }

    pointer operator->()
    {
        return exposer_.ptr();
    }

    const pointer operator->() const
    {
        return exposer_.ptr();
    }

    custom_iterator& operator++()
    {
        ++it_;

        return *this;
    }

    bool operator==(const custom_iterator& other) const
    {
        return it_ == other.it_;
    }

    bool operator!=(const custom_iterator& other) const
    {
        return !(*this == other);
    }

private:

    something_that_exposes_the_type exposer_;
};

For varius reasons, none of which are interesting to others right now, I recently felt a deep need to refresh my university knowledge on the Fourier transform (decomposition of a signal into its constituent frequencies), the DFT (discretization of a Fourier transform) and the FFT (swift computation of the DFT).

I found a, simply stated, fantastic visual set of explanations of what all of this is actually about, for those that doesn’t settle with numbers alone:

• Wikipedia on the Fourier transform (the theory behind the visuals below)
• Understanding the Fourier transform (loads of good comments follows the blog post)
• Animations for DFT (linked from the comments mentioned above)
• fftvisualize (linked from the comments mentioned above)

http://www.objectmentor.com/resources/articles/xpepisode.htm

Far, far from most other canned TDD example scenarios out there. Read it!

http://www.dirigibleflightcraft.com/kindle/

Oh, my… want it.

• First, since I do most of my professional activities with the .NET Compact Framework on handheld devices, I needed an IOC container that supported my main platform. Only Ninject did that at the time.
• Second, the container I choose cannot fail miserably for several of my main usage scenarios. Ninject did that.

Therefore I set out to write my own IOC container with no more bells and whistles than I needed while waiting for the Ninject bug to be fixed. I’m now using my container, the WeeContainer, in production and Ninject still has the bug. So I guess my call was appropriate – it wasn’t a case of YAGNI.

In this post I’ll look deeper into the implementation of WeeContainer to show just how little one need to do if the feature set is kept at a minimum. I’ll attack the codebase outside-in, jumping onto the public interface of WeeContainer and working my way into its not so deep core.

This is the state of WeeContainer:

public sealed class WeeContainer
{
    private readonly Dictionary<Type, BindingTarget> targets = new Dictionary<Type, BindingTarget>();
    private readonly Lifetime defaultLifetime;
    ...
}

We see that the container has a dictionary, mapping a Type to a BindingTarget. There’s also a default lifetime that will be used for all resolved dependencies unless no other lifetime is explicitly set.

The default lifetime cannot be changed after construction of the container – I see no practical benefit to allow the default lifetime to be changed halfway through the process of registering dependencies at the application composition root. At least no benefit that can keep the implementation complexity at a minimum while the client code readability is kept at a maximum.

Why is a Type mapped to a BindingTarget in the dictionary then? When a client asks the container to resolve a dependency of type T, the container is checked for an entry with the Type of T as key. The value of the dictionary entry with that key is a BindingTarget instance that defines everything that is needed to get an instance of the sought dependency.

This is how WeeContainer is constructed:

public sealed class WeeContainer
{
    ...
    public WeeContainer()
        : this(Lifetime.Transient)
    {
    }

    public WeeContainer(Lifetime defaultLifetime)
    {
        Precondition.IsInRange(defaultLifetime, Lifetime.Transient, Lifetime.Singleton, "lifetime");

        this.defaultLifetime = defaultLifetime;
    }
    ...
}

All that is done during construction is setting the default lifetime. Note the use of the utility contract method Precondition.IsInRange to guarantee that the container is in a usable state after construction.

To register a dependency, one uses the first of only two public methods of WeeContainer (obviously except for the constructors):

public sealed class WeeContainer
{
    ...
    public IBindingTarget Bind<T>()
    {
        return this.targets.Create(typeof(T), () => new BindingTarget(typeof(T), this.defaultLifetime));
    }
    ...
}

The utility DictionaryExtensions.Create<TKey, TValue> method that is used above is a sibling of DictionaryExtensions.GetOrCreate<TKey, TValue>. In WeeContainer.Bind<T> a mapping between the Type of type T to a BindingTarget with the default lifetime is added. This BindingTarget is returned as an IBindingTarget.

• If the returned IBindingTarget isn’t further used by the client, then this dependency will resolve its own type, e.g., calling Bind<Foo>() will resolve an actual Foo instance with the default lifetime.
• If the dependency should map an abstract type to a concrete type, then IBindingTarget.To<T>() must be called, e.g., calling Bind<IFoo>().To<Foo>() will resolve a concrete Foo instance with the default lifetime when an IFoo instance is requested.
• If the resolved dependency shouldn’t have the default lifetime, then IBindingTarget.With<T>() or IBindingSource.With<T>() must be called. The IBindingSource instance is returned when calling IBindingTarget.To<T>().

The main purpose of the IBindingTarget and IBindingSource interfaces is to facilitate the WeeContainer fluent interface:

var container = new WeeContainer();

container.Bind<Foo>();                          // Using default lifetime.
container.Bind<IBar>().To<Bar>();               // Using default lifetime.

container.Bind<Baz>().With(Lifetime.Singleton); // Not using default lifetime.

container.Bind<IFoobar>().With(Lifetime.Singleton).To<Foobar>(); // Same effect as next line. The To/With order doesn't matter.
container.Bind<IBaz>().To<Baz>().With(Lifetime.Singleton);       // Same effect as previous line. The To/With order doesn't matter.

To resolve a dependency, one uses the second public method of WeeContainer:

public sealed class WeeContainer
{
    ...
    public T Resolve<T>()
    {
        return (T)Resolve(typeof(T));
    }
    ...
}

This method just delegates the work to the private method Resolve(Type):

private object Resolve(Type targetType)
{
    var target = default(BindingTarget);
    var targetExists = this.targets.TryGetValue(targetType, out target);
    Precondition.IsTrue(targetExists, "targetExists");

    return target.Singleton ?? CreateInstance(target);
}

This method first checks the contract that the requested type must have been previously registered with the container. Then a quick check to see if the found BindingTarget represents an already created dependency with singleton lifetime. If so, then it’s immediately returned, otherwise a new instance of the type defined by the BindingTarget is created in CreateInstance:

private object CreateInstance(BindingTarget target)
{
    var constructors = target.Source.Type.GetConstructors();
    Precondition.IsNotNullOrEmpty(constructors, "constructors");

    var parameters = constructors[0].GetParameters();
    var instance = parameters.Length > 0 ?
                   constructors[0].Invoke(parameters
                                          .Select(parameter => Resolve(parameter.ParameterType))
                                          .ToArray()) :
                   Activator.CreateInstance(target.Source.Type);

    if (target.Lifetime == Lifetime.Singleton && target.Singleton == null)
    {
        target.Singleton = instance;
    }

    return instance;
}

This method actually contains most of the intelligence that can be attributed to WeeContainer and the original idea for this isn’t my own. I’ve previously mentioned that I started things off with Ken Egozi’s blog post It’s My Turn To Build An IoC Container In 15 Minutes and 33 Lines and Ayende Rahien’s prequel Building an IoC container in 15 lines of code. What I did was applying my own coding style to it, added basic lifetime management and made it use a fluent interface.

Anyway, in WeeContainer.CreateInstance I begin by using reflection on the source type to check the contract that a registered source type must be constructible, i.e., it must have at least one public constructor.

Then the first constructor is examined for its parameters, and this is a limitation of WeeContainer: Only the first found constructor is examined. This will rule out types with overloaded constructors, but since that’s something I generally don’t use, it’s not a problem for me. As stated before: the container has what I need, nothing more.

• If the constructor has no parameters, then an instance of the type is constructed using System.Activator.CreateInstance.
• If the constructor has parameters, then instances of the parameter types are recursively created by calling WeeContainer.Resolve(Type) for all of them.

When an instance has been created, it’ll be attached to a BindingTarget if its lifetime is Lifetime.Singleton so that the return statement in WeeContainer.Resolve(Type)

return target.Singleton ?? CreateInstance(target);

can be shortcut when possible. And this is really all there is to it.

All of the above, including NUnit dependencies, can be fetched from the Mercurial repository at https://joger.googlecode.com or cloned with hg clone https://joger.googlecode.com/hg/ joger.

CodeCast Episode 105: Technical Debt with Gary Short and Markus Egger

So. Spot. On.

I thought of adding support for a more fluent interface, since “all the other ones do it” … But I decided that I didn’t need it.

Well, hmmm… After that post I was a bit curious how things would actually look, design-wise, if they were fluent-ized. So I changed the design and then I didn’t want to go back, because I liked the new one better.

The old way of registering types with the IOC container:

public sealed class WeeContainer
{
    ...
    public void Bind<TTarget>() { ... }
    public void Bind<TTarget>(Lifetime lifetime) { ... }

    public void Bind<TTarget, TSource>() { ... }
    public void Bind<TTarget, TSource>(Lifetime lifetime) { ... }
    ...
}

And the new way:

public sealed class WeeContainer
{
    ...
    public IBindingTarget Bind<T>() { ... }
    ...
}

The most obvious difference between the old and new WeeContainer is that its public interface has become much lighter. This has a cost associated with it: The new design has introduced several new types that add complexity to the code base and that requires new tests.

Using the new WeeContainer is probably easier, since there’s only one public method that registers types with the container. Before, there were four methods to choose from.

If a type should be resolved by itself, meaning that it’s instantiatable, using the default lifetime, then calling WeeContainer.Bind<T>() is enough. But if it should be resolved by another type or use another lifetime, then the return value from WeeContainer.Bind<T>() needs to be used, namely the IBindingTarget:

public interface IBindingTarget
{
    IBindingSource To<T>();
    IBindingTarget With(Lifetime lifetime);
}

From IBindingTarget we can conclude that a type registered with WeeContainer.Bind<T>() can get a lifetime other than the default if IBindingTarget.With(Lifetime) is called. The type can also be resolved by another type by calling IBindingTarget.To<T>():

var container = new WeeContainer();
container.Bind<Foo>().With(Lifetime.Singleton);
container.Bind<IBar>().To<Bar>();

Since IBindingTarget.With(Lifetime) returns the IBindingTarget instance, we can fluently add a call to IBindingTarget.To<T>():

container.Bind<IBar>().With(Lifetime.Singleton).To<Bar>();

As you can see, IBindingTarget.To<T>() returns an IBindingSource instance:

public interface IBindingSource
{
    void With(Lifetime lifetime);
}

This interface makes it possible to change the order of the above fluent call to

container.Bind<IBar>().To<Bar>().With(Lifetime.Singleton);

which often feels more natural.

I will look at the implementation of this new fluent interface for WeeContainer and its friends in another post.

public sealed class Frobblarium
{
    private readonly Dictionary<string, Frobble> frobbles;
    ...
    public Frobble GetNamedFrobble(string name)
    {
        Frobble frobble;

        if (!this.frobbles.TryGetValue(name, out frobble))
        {
            frobble = new Frobble();
            this.frobbles[name] = frobble;
        }

        return frobble;
    }
}

The codeblock inside GetNamedFrobble just drives me crazy every time I have to write it manually. Therefore I added some extension methods to overcome this hangup. With those, all that’s left on the manual side of it is this:

public sealed class Frobblarium
{
    private readonly Dictionary<string, Frobble> frobbles;
    ...
    public Frobble GetNamedFrobble(string name)
    {
        return this.frobbles.GetOrCreate(name);
    }
}

So much lighter on both eyes and fingers! The GetOrCreate used above will create the dictionary value by invoking its default constructor. There are two overloaded GetOrCreate extension methods: One that takes a default value to insert into the dictionary if the key doesn’t exist, instead of creating a new value:

public sealed class Frobblarium
{
    private readonly Dictionary<string, Frobble> frobbles;
    private static readonly Frobble defaultFrobble;
    ...
    public Frobble GetNamedFrobble(string name)
    {
        return this.frobbles.GetOrCreate(name, defaultFrobble);
    }
}

The other takes a Func<T> delegate that is used to create a new value (in some other way than by using the default constructor) if the key doesn’t exist.

public sealed class Frobblarium
{
    private readonly Dictionary<string, Frobble> frobbles;
    ...
    public Frobble GetNamedFrobble(string name)
    {
        return this.frobbles.GetOrCreate(name, () => new Frobble { Name = name });
    }
}

Implementation:

public static class DictionaryExtensions
{
    public static TValue GetOrCreate<TKey, TValue>(this IDictionary<TKey, TValue> dictionary, TKey key)
        where TValue : new()
    {
        TValue value;

        if (!dictionary.TryGetValue(key, out value))
        {
            value = new TValue();
            dictionary[key] = value;
        }

        return value;
    }

    public static TValue GetOrCreate<TKey, TValue>(this IDictionary<TKey, TValue> dictionary, TKey key, TValue missingValue)
    {
        TValue value;

        if (!dictionary.TryGetValue(key, out value))
        {
            value = missingValue;
            dictionary[key] = value;
        }

        return value;
    }

    public static TValue GetOrCreate<TKey, TValue>(this IDictionary<TKey, TValue> dictionary, TKey key, Func<TValue> valueProvider)
    {
        TValue value;

        if (!dictionary.TryGetValue(key, out value))
        {
            value = valueProvider();
            dictionary[key] = value;
        }

        return value;
    }
}

A couple of tests for the extension methods:

[TestFixture]
sealed class DictionaryExtensionsTest
{
    [Test]
    public void getorcreate_existing_key_returns_its_value()
    {
        var sut = new Dictionary<int, object>();
        sut[1] = new object();
        sut[3] = new object();
        sut[5] = new object();
        var beforeCount = sut.Count;

        var actual1 = sut.GetOrCreate(1);
        var actual3 = sut.GetOrCreate(3);
        var actual5 = sut.GetOrCreate(5);
        var afterCount = sut.Count;

        Assert.AreSame(sut[1], actual1);
        Assert.AreSame(sut[3], actual3);
        Assert.AreSame(sut[5], actual5);
        Assert.AreEqual(beforeCount, afterCount);
    }

    [Test]
    public void getorcreate_missing_key_returns_new_value()
    {
        var sut = new Dictionary<int, object>();
        sut[1] = new object();
        sut[3] = new object();
        sut[5] = new object();
        var beforeCount = sut.Count;

        var actual0 = sut.GetOrCreate(0);
        var missingValue = new object();
        var actual2 = sut.GetOrCreate(2, missingValue);
        var providedValue = new object();
        var actual4 = sut.GetOrCreate(4, () => providedValue);
        var afterCount = sut.Count;

        Assert.AreSame(sut[0], actual0);
        Assert.AreSame(sut[2], actual2);
        Assert.AreSame(sut[2], missingValue);
        Assert.AreSame(sut[4], actual4);
        Assert.AreSame(sut[4], providedValue);

        Assert.AreNotSame(sut[1], actual0);
        Assert.AreNotSame(sut[3], actual0);
        Assert.AreNotSame(sut[5], actual0);

        Assert.AreNotSame(sut[1], actual2);
        Assert.AreNotSame(sut[3], actual2);
        Assert.AreNotSame(sut[5], actual2);

        Assert.AreNotSame(sut[1], actual4);
        Assert.AreNotSame(sut[3], actual4);
        Assert.AreNotSame(sut[5], actual4);

        Assert.AreEqual(beforeCount + 3, afterCount);
    }
}

All of the above, including NUnit dependencies, can be fetched from the Mercurial repository at https://joger.googlecode.com or cloned with hg clone https://joger.googlecode.com/hg/ joger.

I’ve mentioned that most of my professional development activities circle around Windows Mobile and Windows CE devices using the .NET Compact Framework. Some time ago when I wanted to take the plunge and start using a proper, established and tested IOC container from out there instead of my hand-rolled manual IOC, I found that none of them supported the .NET Compact Framework. Except one: Ninject.

As happy as I was to find at least one IOC container that I could finally swap out my manual IOC for, as sad I became when I could not use it all the way: I tracked down a devious failure in my application as being a bug in the way Ninject handles attributes. This was a showstopper. Remo Gloor of the Ninject project commented on my Stack Oveflow question that he added the issue to their backlog. But I couldn’t wait for the next Ninject version to happen and I didn’t ever want to go back to the manual IOC I had been doing up until lately – the code base size just wasn’t small enough any more.

So, I decided to look into this myself. I decided that I only needed something that could do these basic things:

• Automatically resolve types bound to themselves. Think concrete types.
• Automatically resolve types bound to other types. Think abstract types vs concrete types.
• Either create a new instance every time a type is resolved, or resuse one single instance. Think transient and singleton lifetimes or scopes.
• Present a simple interface.

What were the minimum required amount of building blocks required to fulfill my basic requirements?

I found Ken Egozi’s blog post It’s My Turn To Build An IoC Container In 15 Minutes and 33 Lines which referenced Ayende Rahien’s prequel Building an IoC container in 15 lines of code. By judging their writings in those posts, neither of the containers was actually meant to be used. But I had to make something that could be used. Enter the WeeContainer.

Functionality-wise, I started with Ken Egozi’s code and added the basic feature of choosing a scope (lifetime) for a binding (defines the source type that maps to a target type): transient or singleton. I had no more lifetime needs than that in the applications I was working on.

Presenting a simple interface was just an issue of choosing proper names and not exposing anything that wasn’t needed. I settled on the following idea:

public sealed class WeeContainer
{
    public BindingScope DefaultScope { get; set; }

    public void Bind<TTarget>() { ... }
    public void Bind<TTarget>(BindingScope scope) { ... }

    public void Bind<TTarget, TSource>() { ... }
    public void Bind<TTarget, TSource>(BindingScope scope) { ... }

    public TTarget Resolve<TTarget>() { ... }
}

I thought of adding support for a more fluent interface, since “all the other ones do it”, to support this:

Bind<Target>().To<Source>().As(BindingScope.Singleton);

But I decided that I didn’t need it. I just find

Bind<Target, Source>(BindingScope.Singleton);

easier to both read and write.

Based on my current codebase I decided that the default scope should be transient. Setting a different scope at bind time shouldn’t change the default scope and changing the default scope after a binding has been made shouldn’t affect that binding’s scope, only the coming ones’:

[Test]
public void default_scope_is_transient_by_default()
{
    var sut = new WeeContainer();
    var expected = BindingScope.Transient;
    var actual = sut.DefaultScope;

    Assert.AreEqual(expected, actual);
}

[Test]
public void default_scope_is_not_changed_when_bind_has_other_scope()
{
    var sut = new WeeContainer();
    var expected = sut.DefaultScope;

    Assert.AreNotEqual(expected, BindingScope.Singleton);

    sut.Bind<List<int>>(BindingScope.Singleton);
    var resolved = sut.Resolve<List<int>>();
    var actual = sut.DefaultScope;

    Assert.AreEqual(expected, actual);
}

[Test]
public void changing_default_scope_does_not_change_previous_binds()
{
    var sut = new WeeContainer();
    Assert.AreEqual(sut.DefaultScope, BindingScope.Transient);
    sut.Bind<IList<int>, List<int>>();
    var resolved1 = sut.Resolve<IList<int>>();
    sut.DefaultScope = BindingScope.Singleton;
    var resolved2 = sut.Resolve<IList<int>>();

    Assert.AreNotSame(resolved1, resolved2);
}

[Test]
public void changing_default_scope_changes_coming_binds()
{
    var sut = new WeeContainer();
    Assert.AreEqual(sut.DefaultScope, BindingScope.Transient);
    sut.DefaultScope = BindingScope.Singleton;
    sut.Bind<IList<int>, List<int>>();
    var resolved1 = sut.Resolve<IList<int>>();
    var resolved2 = sut.Resolve<IList<int>>();

    Assert.AreSame(resolved1, resolved2);
}

Furthermore, if I introduce a bug in my code I want the code to fail fast and hard to make it easier to find it and minimize the risk that it makes damage to important data. Therefore early checks must be done to verify that types can actually be instantiated:

class NoPublicCtor : IDisposable
{
    private NoPublicCtor() { }

    public void Dispose()
    {
    }
}

[Test]
public void binding_to_type_without_public_ctor_throws()
{
    var sut = new WeeContainer();

    Assert.Throws<AgumentException>(() => sut.Bind<NoPublicCtor>());
    Assert.Throws<AgumentException>(() => sut.Bind<NoPublicCtor>(BindingScope.Singleton));
    Assert.Throws<AgumentException>(() => sut.Bind<IDisposable, NoPublicCtor>());
    Assert.Throws<AgumentException>(() => sut.Bind<IDisposable, NoPublicCtor>(BindingScope.Singleton));
}

[Test]
public void binding_to_abstract_type_throws()
{
    var sut = new WeeContainer();

    Assert.Throws<AgumentException>(() => sut.Bind<IList>());
    Assert.Throws<AgumentException>(() => sut.Bind<IEnumerable, IList>());
    Assert.Throws<AgumentException>(() => sut.Bind<IList>(BindingScope.Singleton));
    Assert.Throws<AgumentException>(() => sut.Bind<IEnumerable, IList>(BindingScope.Singleton));
}

I think the WeeContainer is good enough while waiting for Ninject to be fixed. I’ll look at the implementation details of WeeContainer in another post. All of the above with more tests, including NUnit dependencies, can be fetched from the Mercurial repository at https://joger.googlecode.com or cloned with hg clone https://joger.googlecode.com/hg/ joger.