Posted on: January 17th, 2013 by jsolutions 19 Comments

The Problem

In object oriented programming, it is very common to have a scenario where a large
number of classes share the same base class and the particular implementation needs
to be created at runtime based on some specific parameters, for example a class name
held in a string.

Standard C++ does not provide the same type of reflection mechanism that other languages
use to achieve this, such as C# :

      .CreateInstance(string className)

or in java:


However, C++ does not allow us to do such things; we have to come up with another solution.
The basic pattern, or set of patterns, that help us achieve this are factory patterns.

A Simple Solution

The Base Class

Our base class is defined as an abstract class as follows:


class MyBaseClass
    virtual ~MyBaseClass(){}
    virtual void doSomething() = 0;


The Factory Class

A factory method can then be defined as a static method that can be used to create
instances of MyBaseClass. We could define this as a static method on MyBaseClass
itself, although it is generally good practice in object oriented development that a class
serves a single purpose. Therefore, lets create a factory class:


#include "MyBaseClass.h"
#include <memory>
#include <string>

using namespace std;

class MyFactory
    static shared_ptr<MyBaseClass> CreateInstance(string name);


The factory method is expected to create an instance of a class named name that is derived
from MyBaseClass and return it as a shared pointer, as it will relinquish ownership
of the object to the caller.

We shall return to the implementation of the method shortly.

Some Derived Classes

So lets implement a couple of derived classes:


#include "MyBaseClass.h"
#include <iostream>
using namespace std;

class DerivedClassOne : public MyBaseClass
    virtual ~DerivedClassOne(){};

    virtual void doSomething() { cout << "I am class one" << endl; }




#include "MyBaseClass.h"
#include <iostream>
using namespace std;

class DerivedClassTwo : public MyBaseClass
    virtual ~DerivedClassTwo(){};

    virtual void doSomething() { cout << "I am class two" << endl; }


A First Attempt at the Factory Method

A simple solution to the implementation of the factory method would be something like

#include "MyFactorySimple.h"

#include "DerivedClassOne.h"
#include "DerivedClassTwo.h"

shared_ptr<MyBaseClass> MyFactory::CreateInstance(string name)
    MyBaseClass * instance = nullptr;

    if(name == "one")
        instance = new DerivedClassOne();

    if(name == "two")
        instance = new DerivedClassTwo();

    if(instance != nullptr)
        return std::shared_ptr<MyBaseClass>(instance);
        return nullptr;

The factory determines which concrete class to create and has knowledge of every class
via the class headers.

Running the application

A simple main function is now needed so that we can test our implementation:

#include "MyFactorySimple.h"

int main(int argc, char** argv)
    auto instanceOne = MyFactory::CreateInstance("one");
    auto instanceTwo = MyFactory::CreateInstance("two");


    return 0;

A Visual Studio Project (SimpleFactory.vcxproj) is included with the source code accompanying
this article which can be built and run giving the following output:

I am class one
I am class two

Problems with the Simple Solution

On the surface this looks like a good solution and it possibly is in some cases. However,
what happens if we have a lot of classes deriving from MyBaseClass? We keep having
to add the includes and the compare – construct code.

The problem now is that the factory has an explicit dependency on all the derived
classes, which is not ideal. We need to come up with a better solution; one that removes
the need for constantly adding to the MyFactory::Create. This is where the idea of a
registry of factory methods can help us.

A Revised Factory Class

One of our main objectives is to remove the dependencies on the derived classes from
the factory. However, we still need to allow the factory to trigger the creation of instances.
One way to do this is for the main factory class to maintain a registry of factory
functions that can be defined elsewhere. When the factory class needs to create an instance
of a derived class, it can look up the factory function in this registry. The registry
is defined as follows:

map<string, function<MyBaseClass*(void)>> factoryFunctionRegistry;

It is a map, keyed on a string with values as functions that return a pointer to an instance
of a class based on MyBaseClass.

We can then have a method on MyFactory which can add a factory function to the registry:

void MyFactory::RegisterFactoryFunction(string name,
function<MyBaseClass*(void)> classFactoryFunction)
    // register the class factory function
    factoryFunctionRegistry[name] = classFactoryFunction;

The Create method can then be changed as follows:

shared_ptr<MyBaseClass> MyFactory::Create(string name)
    MyBaseClass * instance = nullptr;

    // find name in the registry and call factory method.
    auto it = factoryFunctionRegistry.find(name);
    if(it != factoryFunctionRegistry.end())
        instance = it->second();

    // wrap instance in a shared ptr and return
    if(instance != nullptr)
        return std::shared_ptr<MyBaseClass>(instance);
        return nullptr;

So how do we go about registering the classes in a way that keeps dependencies to a
minimum? We cannot easily have instances of the derived classes register themselves
as we can’t create instances without the class being registered. The fact that we need the
class registered, not the object gives us a hint that we may need some static variables
or members to do this.

I stress that the way I am going to do this may not be the best in all scenarios. I am deeply
suspicious of static variables and members, as static initialisation can be a minefield.
However, I will press on, as the solution serves the purpose of this example and it is up
to the reader to determine whether a solution they use needs to follow different rules
and design.

Firstly we define a method on MyFactory to obtain the singleton instance:

MyFactory * MyFactory::Instance()
    static MyFactory factory;
    return &factory;

We cannot call the following from the global context:

MyFactory::Instance()->RegisterFactoryFunction(name, classFactoryFunction);

I have therefore created a Registrar class that will do the call for us in it’s constructor:

class Registrar {
    Registrar(string className, function<MyBaseClass*(void)> classFactoryFunction);
Registrar::Registrar(string name, function<MyBaseClass*(void)> classFactoryFunction)
    // register the class factory function 
    MyFactory::Instance()->RegisterFactoryFunction(name, classFactoryFunction);

Once we have this, we can create static instances of this in the source files of the derived
classes as follows (DerivedClassOne):

static Registrar registrar("one",
[](void) -> MyBaseClass * { return new DervedClassOne();});

As it turns out, this code can be duplicated in all derived classes so a quick pre processor
define as follows:

    static Registrar registrar(NAME, \
        [](void) -> MyBaseClass * { return new TYPE();});

This uses the new C++ lambda support to declare anonymous functions. We then
only need add the following to each derived class source file:

REGISTER_CLASS("one", DerivedClassOne);

Update 25th January 2013

We Can Do Better …

Although the #define solution provides a neat implementation we could probably do this in a bit more of a C++ style by converting the Registrar class into a template class as follows:

template<class T>
class Registrar {
    Registrar(string className)
        // register the class factory function 
                [](void) -> MyBaseClass * { return new T();});

And now we can replace the use of the macro by

static Registrar<DerivedClassOne> registrar("one");

We now have a function registry based factory class defined and the main function can
now be slightly modified as follows:

#include "MyFactory.h"

int main(int argc, char** argv)
    auto instanceOne = MyFactory::Instance()->Create("one");
    auto instanceTwo = MyFactory::Instance()->Create("two");


    return 0;

We can now build and run the project and get the following output:

I am class one
I am class two


Factory (software concept) – Wikipedia: http://

Factory Method Pattern – Wikipedia: http://

Abstract Factory Pattern – Wikipedia: http://

C++ 11 – Wikipedia:

Source Code

Tags: , ,

19 Responses

  1. PM says:

    It’s a shame nobody else has left a comment yet. This factory system works perfect! I’ve seen the macro system being used in OSG and Urho3D for example (if I’m right) but the C++ way is much better, thank you! :)

    • jsolutions says:

      Thanks for your comments. I have made slight modifications to this pattern over the past year, but generally only to make automated code generation easier. I have a lot of classes that represent XML elements and this pattern makes it very simple to automate some of the boilerplate code generation.

      I find the fact that it has been so simple to work with this pattern and I have been able to leave most of the code above unchanged most encouraging :)

  2. Vishnu says:


    Thanks for the post.

    I couldn’t understand the below code. Can you please explain?

    static Registrar registrar(“one”,
    [](void) -> MyBaseClass * { return new DervedClassOne();});


    • jsolutions says:

      Put simply, registrar is a static instance (ie scoped to the file it is declared in) of a Registrar object. The constructor of the registrar takes 2 arguments:

      “one” is string to determine the key to use in finding the creation function in the factoryFunctionRegistry map described above.
      the second argument is the creation function defined as a lambda function (C++11)

      I hope that helps?

  3. Vishnu says:

    Thanks for the replay. I got the static part. I had no idea about lambda function. Time to learn C++11. :) Thanks again.

  4. kris lamb says:

    This is really nice, im going to implement something very similar but keep an object cache of weak pointers so i can easily lookup already existing objects. The only thing i havent figured out yet is when to do the “garbage collection” to clear unpointed to objects. I suppose i could keep another low priority thread running that checks every once in a while for unused objects. Either that or have the base destructor clean it up… hmmm…

    • jsolutions says:

      I would do something like this:

      (I have used a static cache… and some of the code might not be exactly correct, as I am writing it without checking.)

      shared_ptr<MyBaseClass> MyFactory::CachedCreate(string name)
      // The cache
      static map<string, weak_ptr> cache;

      // will create a new empty weak_ptr if it don't exist
      shared_ptr<MyBaseClass> res = cache[name];

      // only if we don't have one in cache, create
      if(res == nullptr) {
      res = Create(name);
      cache[name] = res;

      return res;

      shared_ptr<MyBaseClass> MyFactory::Create(string name)
      // same code as above

      I believe this kind of strategy should manage the lifetime through shared_ptr. So when no instances of the shared_ptr to the raw pointer exist, the final shared_ptr destructor should delete its object and cache[name] will return an empty weak_ptr, as it would if no weak_ptr existed for name.

      Don’t you just love C++ :)

  5. Very nice explanation, really one of the best I have seen while searching for the factory pattern in c++

  6. Vladimir Jovic says:

    You are missing the virtual destructor in MyBaseClass. Same in the article.

    This means you are missing some basic c++ knowledge.

    Anyway, I find your ideas quite good. With some fixes, your blogs would be much better.

    • jsolutions says:

      Oops, my bad! I’m well aware for the need for virtual destructors in inheritance hierarchies – these slipped through the net.

  7. Dan says:

    Thanks for this useful description of a c++ object factory.

    Previously I have been implementing something similar to your ‘simple’ solution. I would like to implement a neater and more flexible solution like yours, but it seems like a lot of extra code especially if the ‘Registrar’ and ‘MyFactory’ classes need to be defined for each base class. Would it be possible to make these templates so they can be defined once and then reused for various base classes?

    Please forgive my naiviety if this is obvious, I’m still learning c++.

    • jsolutions says:

      Thanks Dan. The registrar does have to be definied for each base class – there has to be some way of registering each class with the Factory. The solution here trims that code right down to the following single lines for each class:

      static Registrar registrar(“one”);
      static Registrar

      static Registrar registrar(“n”);

      using the Registrar class as the template you talk about. I really don’t see any way round this other than just moving that particular line about. There will always need to be a single global / static member defined as above.

      In the project that I use this in extensively, all these lines are generated by a pre build step using some XSLT (in fact a whole load of boiler plate is generated with XSLT).

      However, the “MyFactory” class is in fact only defined once and does not need to be redefined for each base class. That is the point of it :)

  8. Diego Jesus says:


    Nice object factory. I think it’s the most useful I’ve seen so far.

    I have one problem, however, and I think it’s related to compiler optimisations.

    I have a hierarchy of classes where class Node (in Node.h/Node.cpp) is the base class and, for example, BuildingLot (in BuildingLot.h/BuildingLot.cpp) is a subclass.

    In both of the source files, declared as static I have a Registrar class.

    static Registrar _registrar(“Node”);
    static Registrar _registrar(“BuildingLot”);

    If I try to use the Factory, it works perfectly for Node class. I, however, have to first create an instance of BuildingLot for it to be registered in the factory.

    In a unit test I have:

    NodePtr node = Factory::Instance()->Create(“Node”);
    NodePtr bl = Factory::Instance()->Create(“BuildingLot”);

    bl is always nullptr. The Registrar constructor is never executed. If I do this:

    BuildingLot b;
    NodePtr node = Factory::Instance()->Create(“Node”);
    NodePtr bl = Factory::Instance()->Create(“BuildingLot”);

    The all works. The Registrar is called, and the Factory creates a BuildingLot.

    I think, since the BuildingLot isn’t used in the first example, the compiler optimised and didn’t even compile the BuildingLot.cpp.

    Is this possible? How can I solve this?

    • jsolutions says:

      I presume the code above should read:

      static Registrar<Node> _registrar(“Node”);
      static Registrar<BuildingLot> _registrar(“BuildingLot”);


    • Jason says:

      I have same issue with Diego. If BuildingLot is not called explicitly, the “BuildingLot” never registered to the factory so bl is always nullptr.

      Any idea?

      • jsolutions says:

        Hi Jason,

        I have not managed to reproduce this yet. What compiler are you using? Is there any chance you can put together an example of it not working and email it to me at and I’ll take a look.


  9. Alex says:

    Hi John,

    Thanks for this great post. I’ve been looking at a lot of things to solve a similar problem that I’m having, and your post was the most helpful.

    A small question: I have many small classes, and groups of them are defined in the same .h and .cpp files. When using your updated technique and instantiate a “Registrar” object for each of my derived classes via the template, and not the macro, I do this:

    static Registrar<RandomFloat> registrar("RandomFloat");
    static Registrar<RandomInt> registrar2("RandomInt");

    I need to give a unique name to each Registrar instance, otherwise my compiler will complain about redefining the variable. But you imply that this shouldn’t be necessary? Is that only in the case where you only register one class per .cpp, and the implicit file level scope resolves it? Or am I missing something?

    • jsolutions says:

      Hi Alex,

      You are correct, if they are all in the same file there will be a naming conflict. My main use for this pattern also has all the registrar instances in a single cpp file, although I auto generate them from XML using XSLT (the XSLT also generates a whole load of other boilerplate code).

Leave a Reply