Archive

Posts Tagged ‘boost’

Eric Niebler: out parameters, move semantics, and stateful algorithms

October 16, 2013 Leave a comment

Eric Niebler: out parameters, move semantics, and stateful algorithms

This post from Eric, inspired by a prompt from Andrei Alexcandrescu, examines the interface of std::getline appraising its usability and performance. Eric looks at a few different designs, in particular those that leverage the move semantics introduced in C++11.

This is a particularly good exploration of a small and simple API – almost too simple to bother with – and Eric’s range-based solution is far more natural and still efficient.  The crux of his design approach stems from the insightful realisation that “getline is a curious example because what looks at first blush like a pure out parameter is, in fact, an in/out parameter; on the way in, getline uses the passed-in buffer’s capacity to make it more efficient. This puts getline into a large class of algorithms that work better when they have a chance to cache or precompute something.

The discussion in the comments below the post also merits reading, particularly Bartosz Milewski’s suggestion that front be thought of as take 1 (take n xs is a function in Haskell that returns a list of the first n elements of the list xs.

Boost compile error “no class template named ‘result’”

January 30, 2013 1 comment

I’ve just come across a compiler error resulting from using boost::result_of with a C++11 lambda.
I wasn’t actually using boost::result_of directly, but provided a lambda as the transforming functor for a boost::transform_iterator, which uses it behind the scenes.

Here’s a small listing that shows the problem:

#include <boost/iterator/transform_iterator.hpp>
#include <iostream>

int main()
{
   int i[] = {1, 2, 3, 4};

   auto square = [](int i) { return i*i; };
   auto begin  = boost::make_transform_iterator( i,   square );
   auto end    = boost::make_transform_iterator( i+4, square );
}

with Boost 1.48 that yields the following error:

In file included from /usr/include/boost/iterator/transform_iterator.hpp:23:0,
                 from boost-result-of-error-with-lambdas.cpp:2:
/usr/include/boost/utility/result_of.hpp: In instantiation of ‘struct boost::detail::result_of_nested_result<main()::, main()::(int&)>’:
/usr/include/boost/utility/result_of.hpp:83:8:   required from ‘struct boost::detail::tr1_result_of_impl<main()::, main()::(int&), false>’
/usr/include/boost/utility/detail/result_of_iterate.hpp:23:8:   required from ‘struct boost::tr1_result_of<main()::(int&)>’
/usr/include/boost/utility/detail/result_of_iterate.hpp:80:8:   required from ‘struct boost::result_of<main()::(int&)>’
/usr/include/boost/mpl/eval_if.hpp:38:31:   required from ‘struct boost::mpl::eval_if<boost::is_same, boost::result_of<main()::(int&)>, boost::mpl::identity >’
/usr/include/boost/iterator/iterator_adaptor.hpp:160:12:   required from ‘struct boost::detail::ia_dflt_help<boost::use_default, boost::result_of<main()::(int&)> >’
/usr/include/boost/iterator/transform_iterator.hpp:50:17:   required from ‘struct boost::detail::transform_iterator_base<main()::, int*, boost::use_default, boost::use_default>’
/usr/include/boost/iterator/transform_iterator.hpp:74:9:   required from ‘class boost::transform_iterator<main()::, int*, boost::use_default, boost::use_default>’
boost-result-of-error-with-lambdas.cpp:10:60:   required from here
/usr/include/boost/utility/result_of.hpp:79:8: error: no class template named ‘result’ in ‘struct main()::’

The problem is that boost::result_of doesn’t play well with C++11 lambdas straight off, fortunately the solution is simple: define preprocessor symbol BOOST_RESULT_OF_USE_DECLTYPE and all is well again :-)

Thanks to Akira Takahashi for the solution in this response to the same issue triggered from the range adaptors.

Categories: Uncategorized Tags: , , ,

On creating an asynchronous message-based c++ framework; part 2

March 10, 2011 2 comments

This is the second post in a series on the creation of an asynchronous message-based C++ application framework.

In part 1 I discussed my approach to defining the type for an object that has a set of observers, and finished up with the following types and public interface:

typedef boost::function observer;
struct message;

struct subject
{
   virtual ~subject() {}

   void registerObserver(observer& o);
   void notifyObservers(const message& m);
};

In this part I will look at how to use a message type hierarchy, and why I think doing so is a Good Thing.

So what is it?

Which is more informative: a message that says “Hi there, FYI the value of foo has changed” or one that says “Hey you! foo is now 729”? Most messages make more sense with some sort of attached context, and since now seems a good time to create a message base class, here’s a basic one for us:

struct message
{
   virtual ~message() {}

   typedef std::string message_id;
   virtual message_id id() const = 0;
};

It’s worth noting at this stage that context should be as specific and fine-grained as possible. Whilst attaching a subject to its messages can make implementation faster, it ain’t proper OO design, and it tightly couples observers to their subjects. (If you must do it, you could keep them decoupled by attaching the subject behind a separate interface type, but shhhhh, I didn’t tell you that.)

Topic-based filtering

How much of a pain would it be if observer implementations resembled the following?

void notify(const message& m)
{
   if      (m.id() == MSGID_FOO_CHANGED)  fooChanged(m)
   else if (m.id() == MSGID_USER_SNEEZED) userSneezed(m)
   //...
}

Enough of a pain that your fingers would drop off out of boredom, that’s how much. To avoid the inconvenience of being fingerless, we’ll implement ‘topic-based filtering’ in the subject, meaning that observers will be registered only to receive the message type(s) they’re interested in. This is a common feature of the ‘publish/subscribe’ pattern, of which the observer pattern is a subset.

Here’s the updated subject definition for topic-based filtering:

struct subject
{
   typedef message::message_id message_id;

   void registerObserver(const message_id& id, const observer& o)
   {
      observers[id].push_back(o);
   }

   // NB: I will tackle removeObserver() in a later post

   void notifyObservers(const message& m)
   {
      BOOST_FOREACH (const observer& o, observers[m.id()])
         o(m);
   }

private:
   typedef std::vector<observer> observer_set;
   typedef std::map<message_id, observer_set> observer_map;
   observer_map observers;
};

And a quick example:

void notify(const message& m)
{ /*...*/ }

void foo()
{
   subject s;
   s.registerObserver(foo_updated::MESSAGE_ID, notify);
}

The eagle-eyed among you may have noticed that in this post I’ve defined observer_set to be a vector of observers, whereas in the previous post I defined it as a vector of pointers to observers. That was a typo – albeit consistent throughout – which in a program of any larger size would likely have led down the path of Undefined Behaviour, so apologies for that.

Downcasting observer decorator

I’d like to finish off with my favourite part of this post. Despite managing to simplify the notify() implementation with topic-based filtering, we still have to downcast and check each message before we can access the message-specific interface. There are, after all, only so many times you can type “blah equals dynamic cast to const foo pointer from bar, if blah not null then…” before your fingers will seize up and that’ll be the end of your programming days.

I’ll create an observer ‘decorator’ which will both wrap an observer and look like one. When notified, it will downcast the message to the type expected by the observer and forward it on.
First we need a generalised observer type templated on the message type. C++ doesn’t support template typedefs, so we employ a common workaround as discussed here by Herb Sutter. (NB: C++0x does support template typedefs under the name ‘template aliases’.) Then we can redefine observer in terms of the generalised type.

template<class message_type>
struct generic_observer
{
    typedef boost::function<void (const message_type&)> type;
};

typedef generic_observer<message>::type observer;

We don’t need to modify the subject definition as it will continue to store instances of observer. Instead, we now define the decorator which does the downcast. Here it is:

template<class message_type>
struct downcasting_observer
{
    typedef typename generic_observer<message_type>::type wrapped_type;

    downcasting_observer(const wrapped_type& observer)
        : obs(observer)
    {}


    void operator()(const message& m)
    {
        const message_type* p = dynamic_cast<const message_type*>(&m);
        if (p)
            obs(*p);
    }

private:
    wrapped_type obs;

};

Here’s a full demo program with all of the above rolled in:

#include <string>
#include <map>
#include <iostream>
#include <vector>
#include <boost/bind.hpp>
#include <boost/function.hpp>
#include <boost/foreach.hpp>

// ------- MESSAGE -------
struct message
{
    virtual ~message() {}

    typedef std::string message_id;
    virtual message_id id() const = 0;
};


// ------- OBSERVER -------
template<class message_type>
struct generic_observer
{
    typedef boost::function<void (const message_type&)> type;
};

typedef generic_observer<message>::type observer;


// ------- DOWNCASTING OBSERVER -------
template<class message_type>
struct downcasting_observer
{
    typedef typename generic_observer<message_type>::type wrapped_type;

    downcasting_observer(const wrapped_type& observer)
        : obs(observer)
    {}


    void operator()(const message& m)
    {
        const message_type* p = dynamic_cast<const message_type*>(&m);
        if (p)
            obs(*p);
    }

private:
    wrapped_type obs;
};



// ------- SUBJECT -------
struct subject
{
    typedef message::message_id message_id;

    void registerObserver(const message_id& id, const observer& o)
    {
        observers[id].push_back(o);
    }


    void notifyObservers(const message& m)
    {
        BOOST_FOREACH (const observer& o, observers[m.id()])
            o(m);
    }

private:
    typedef std::vector<observer> observer_set;
    typedef std::map<message_id, observer_set> observer_map;
    observer_map observers;
};



// ------- USAGE DEMO -------
struct foo_updated: public message
{
    foo_updated(int foo)
        : foo(foo)
    {}

    message_id id() const
    { return MESSAGE_ID; }

    const int foo;
    static const message_id MESSAGE_ID;
};
const message::message_id foo_updated::MESSAGE_ID("foo_updated");


void notify(const foo_updated& m)
{
   std::cout << "foo was updated to " << m.foo << std::endl;
}


int main()
{
    subject s;
    s.registerObserver(foo_updated::MESSAGE_ID, downcasting_observer<foo_updated>(notify));
    foo_updated m(42);
    s.notifyObservers(m);
}

You can see that the subject usage there doesn’t have to have any control structures to determine what it’s been given or to downcast it. All of those decisions are hidden behind the filtering enabled by the observer_map instance and the downcasting_observer.

Double dispatch as an alternative

An alternative mechanism to the decorator could be to employ ‘double dispatch‘, with the subject instead calling “message::notifyObserver(observer&)”, and the message then passing itself to the observer with its own type, rather than the base. To achieve this, message would have to be a template class, and an additional, non-templated base for message<T> would be required to store instances in a container together. Finally, this base would need to have one overloaded notify() method per message type.
Whilst this technique can be useful, I’m not a fan of this proliferation of types into the base, and as such don’t often use it. It would be particularly impractical for an API to need updating every time the application developer wanted to add a new message type.

Wrap-up

This post became rather larger than I’d hoped, so I hope it’s still digestible. The decorator pattern is a great one for extending functionality without modifying the wrapped object, and in a way this really exemplifies the ideal mechanism of extending functionality in an OO environment. Though C++0x does away with the need for the template typedef workaround, not everybody will have the luxury of using it and it’s a good one to have up your sleeve.

The next post will be a shorter one; I’ll be looking at the message types a little more closely, and show how we can use the ‘Curiously Recurring Template Pattern’ (CRTP) to prevent repetitive boilerplate in them. Happy coding!

Categories: Uncategorized Tags: , ,

On creating an asynchronous message-based c++ framework; part 1

February 25, 2011 7 comments

This is the first post in a series on the creation of an asynchronous message-based C++ application framework. The series will in particular show the use of several parts of the excellent Boost C++ libraries to achieve this, and the application of several design patterns in a real-world context. I will also show the evolution of this framework during the series, so you can understand the decisions I made and see the problems I came up against, rather than just a polished end-result.

Requirements

Firstly, then, a few requirements and design considerations. I want my framework to:

  • Implement an asynchronous message-based notification system to enable the decoupling of data consumers from data producers. This decoupling will help to keep the design modular, and makes unit testing easier.
  • Provide the facility to monitor for read/write readiness of files (including regular files, pipes, sockets, and hardware device).
  • Provide the facility to schedule timed events (ignoring latency induced by processing and the scheduler).

The first piece: a storable observer type

We will start off with the observer pattern, since much of the rest of the functionality hinges on this and it will form the core of the message delivery mechanism. It is a common pattern that also crops up as a subset of other well-known patterns, so hopefully it will be familiar to the majority of you.

The subject – the object being observed – will need to be able to store a set of observer references. As I will want an object to observe more than 1 subject, we need to be able to register different methods of different classes as observers.

To store pointers-to-members of different classes in the same type with type-safety, both classes would need to derive from a common base; we could then store a pointer-to-member of either in a void (base::*)() pointer. We would also have to store a reference to each registered observer instance. This is doable, but it involves some dull typing, and excludes the following from being observers:

  • Classes I cannot change (e.g. third-party/legacy code)
  • Free functions
  • Static member functions

Instead, I elected to use boost::function, since it provides the following benefits:

  • It can wrap pointers to free functions, static and non-static member functions, and functors (function objects)
  • It can wrap any member function without need to modify the class definition
  • It is easy to use with boost::bind, so binding an instance to a method is a no-brainer, with the added bonus that we can bind additional parameters too without modifying the subject.

Let’s define our observer type, and then we can define the type of a container of observers too. We’ll make each observer take some ‘message’ type which can provide information about the notification.

typedef boost::function<void (const message&)> observer;
typedef std::vector<observer*> observer_set;

Subjects and their observers

Implementing that behind the typical interface for an observable subject, we can create a base class for subjects like so:

struct subject
{
   virtual ~subject() {}

   void registerObserver(observer& o) {
      observers.push_back(&o);
   }

   // unregisterObserver unimplemented for now...

   void notifyObservers(const message& m) {
      BOOST_FOREACH (observer* o, observers)
         (*o)(m);
   }

private:
   typedef std::vector<observer*> observer_set;
   observer_set observers;
};

And a complete test program:

#include <boost/bind.hpp>
#include <boost/function.hpp>
#include <boost/foreach.hpp>
#include <iostream>
#include <vector>
using namespace std;

typedef int message;
// simple for now: each message is an event type identifier (like windows messages)
typedef boost::function<void (const message&)> observer;

struct subject
{
    virtual ~subject() {}

    void registerObserver(observer& o) {
        observers.push_back(&o);
    }

   // unregisterObserver unimplemented for now...

    void notifyObservers(const message& m) {
        BOOST_FOREACH (observer* o, observers)
            (*o)(m);
    }

private:
    typedef std::vector<observer*> observer_set;

    observer_set observers;
};

void notify(const message& m)
{
    cout << "notify: got message " << m << endl;
}

struct MyObserver
{
    void notify(const message& m, const char* name) {
        cout << "MyObserver::notify [" << name << "] got message " << m << endl;
    }
};

int main()
{
    subject s;
    MyObserver mo;

    observer oFree(&notify);
    char name[] = "bobs";
    observer oMember(boost::bind(&MyObserver::notify, &mo, _1, name));

    s.registerObserver(oFree);
    s.registerObserver(oMember);
    s.notify(12);
}

The last word…

Now that we have the primary building block of the framework – the types for subjects and observers – I’ll be looking next at how to implement a message type hierarchy and will apply the decorator pattern in doing so. Part 2 will trundle along sometime in the next fortnight, so thanks for reading and in the meantime please leave any comments or suggestions below.

Categories: Uncategorized Tags: , ,
Follow

Get every new post delivered to your Inbox.