Category Archives: C++

Building Anti-Grain Geometry without SDL

A short post about an annoying problem while building AGG 2.4:
If you don’t have SDL installed, the build fails because of

aclocal:configure.in:103: warning: macro `AM_PATH_SDL' not found in library
configure.in:103: error: possibly undefined macro: AM_PATH_SDL
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

Installing SDL solves this problem, but if you want to skip this, hereโ€™s a shorter workaround:

$ echo โ€œAC_DEFUN([AM_PATH_SDL])โ€ > acinclude.m4

Continue as usual with

$ source .autogen.sh
$ ./configure
$ make
$ sudo make install

C++ metaprogramming

A completely useless but fun-to-write example for C++ template metaprogramming. Did you ever wanted to calculate the control digit of a UIC wagon number at compile-time? This serves just as an example that any computer algorithm can be implemented in some way in a template metaprogram (template metaprogramming is generally Turing-complete).

#include <iostream>

template <long long u, int m>
struct S
{
    static long long const val = S<u/10, m%2+1>::val + ((u%10)*m)/10 + ((u%10)*m)%10;
};

template <int m>
struct S<0, m>
{
    static long long const val = 0;
};

template <long long u>
struct UIC
{
    static long long const val = u*10+(10-S<u,2>::val%10)%10;
};

int main()
{
    std::cout << UIC<21812471217LLU>::val << std::endl;
    return 0;
}

As one would expect, the output is 218124712173 ๐Ÿ™‚

C++ singleton with policies

The traditional Singleton pattern only supports a default constructor (one that takes no arguments), but recently I needed to create a singleton from a class which required an integer argument in its constructor.

This can be solved quite elegantly with a policy-based design. Take a look at the following (non thread-safe!) implementation:

#ifndef SINGLETON_HPP
#define SINGLETON_HPP

// Creation policies
template<class T> struct CreateWithIntParameter
{
    static T* Create()
    {
        return new T(m_intParameter);
    }
    static const int m_intParameter;
};

// Non-thread-safe singleton
template <class T, template<class> class CreationPolicy>
class Singleton
{
public:
    static T& instance()
    {
        if (!m_instance)
        {
            m_instance = CreationPolicy<T>::Create();
        }
        return *m_instance;
    }
private:
    Singleton();
    Singleton(const Singleton&);
    Singleton& operator=(const Singleton&);

    static T* m_instance;
};

template <class T, template<class> class C>
T* Singleton<T, C>::m_instance = 0;

#endif // SINGLETON_HPP

Here is a small example how to use it:

#include "singleton.hpp"
#include <iostream>

using namespace std;

class Foo
{
public:
    Foo(int a) : m_a(a)
    {
        cout << "Foo constructed" << endl;
    }
    void bar()
    {
        cout << "a = " << m_a << endl;
    }
private:
    Foo();
    int m_a;
};

template<> const int CreateWithIntParameter<Foo>::m_intParameter = 5;

typedef Singleton<Foo, CreateWithIntParameter> FooSingleton;

int main()
{
    FooSingleton::instance().bar();
    FooSingleton::instance().bar();
    return 0;
}

The output looks like this:

Foo constructed
a = 5
a = 5

A boost::statechart example

How would you transform a statechart (David Harel statechart, or UML state diagram if you like) into executable C++ code? You can use one of the many free and commercial tools that are able to generate very efficient C or C++ code from statecharts, but you can also do so without needing such a tool: you might also consider using the Boost statechart library.

For a simple example, consider the following scenario :
Assume a controller has one push button switch wired to an input, and one lamp wired to an output. The first time the button is pressed the lamp must come on. The next time the button is pressed, the lamp must turn off. On the next press the lamp comes on, etc. etc. Don’t forget to allow for the button to be released before it is pressed again.

Sounds easy, doesn’t it? However, often the required behavior is not so trivial (when we’d like to restore previous state, or when reactions depend on the active state in many orthogonal regions). In this case, I typically use a statechart design. IMO this method scales up very well to large and complicated systems.

A possible solution for our example looks like this: We have two orthogonal regions, one region with two states for button pressed/released and another region with light on/off.
The statechart

As with many of the Boost libraries, boost::statechart is header-only and uses templates quite heavily. In general, the documentation is quite good, so don’t be afraid to read it. There is also an excellent tutorial for those just starting out, with plenty of examples.

So without further ado, here’s the source code that implements the statechart from above:

#include <boost/statechart/event.hpp>
#include <boost/statechart/state_machine.hpp>
#include <boost/statechart/simple_state.hpp>
#include <boost/statechart/state.hpp>
#include <boost/statechart/transition.hpp>
#include <boost/mpl/list.hpp>
#include <iostream>

using namespace std;

namespace sc = boost::statechart;
namespace mpl = boost::mpl;

struct EvPressButton : sc::event<EvPressButton>
{
  EvPressButton()
  {
    cout << "Button is pressed" << endl;
  }
};

struct EvReleaseButton : sc::event<EvReleaseButton>
{
  EvReleaseButton()
  {
    cout << "Button is released" << endl;
  }
};

struct EvToggleLight : sc::event<EvToggleLight> {};

struct Active;
struct Switch : sc::state_machine<Switch, Active> {};

struct ButtonReleased;
struct ButtonPressed;
struct LightOff;
struct LightOn;

struct Active: sc::simple_state<Active, Switch,mpl::list<ButtonReleased, LightOff> > {};
struct ButtonPressed : sc::state<ButtonPressed, Active::orthogonal<0> >
{
  typedef sc::transition<EvReleaseButton, ButtonReleased> reactions;
  ButtonPressed(my_context ctx) : my_base(ctx)
  {
    post_event(EvToggleLight());
  }
};

struct ButtonReleased : sc::simple_state<ButtonReleased, Active::orthogonal<0> >
{
  typedef sc::transition<EvPressButton, ButtonPressed> reactions;
};

struct LightOff : sc::simple_state<LightOff, Active::orthogonal<1> >
{
  typedef sc::transition<EvToggleLight, LightOn> reactions;
  LightOff()
  {
    cout << "Light is off" << endl;
  }
};

struct LightOn : sc::simple_state<LightOn, Active::orthogonal<1> >
{
  typedef sc::transition<EvToggleLight, LightOff> reactions;
  LightOn()
  {
    cout << "Light is on" << endl;
  }
};

int main()
{
  Switch sw;
  sw.initiate();
  for (int i = 0; i < 5; i++)
  {
    sw.process_event(EvPressButton());
    sw.process_event(EvReleaseButton());
  }
  return 0;
}

The output:

Light is off
Button is pressed
Light is on
Button is released
Button is pressed
Light is off
Button is released
Button is pressed
Light is on
Button is released
Button is pressed
Light is off
Button is released
Button is pressed
Light is on
Button is released

Which looks about right, I think. ๐Ÿ™‚