Boost logo

Boost :

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-11-21 19:05:32

On Wednesday 21 November 2001 05:31 pm, you wrote:
> Ok, I guess I was a bit too busy thinking that a general purpose
> functor like boost::function should mimick a plain vanilla function
> pointer as closely as possible ...
> However, my claim is that equality operations would simplify the
> usage since most C++ programmers know what a function pointer does
> and how to deal with it.

I completely understand this viewpoint, but I personally believe that
function pointers are an artifact of C that unfortunately must live on in
C++. I've likened them to C-style arrays: they're an artifact of C we can't
get rid of, but boost::array has much more C++-like semantics and it is
generally preferred. boost::array is to C-style arrays as boost::function is
to function pointers, I think.

> As with C# delegates (I'm no Microsoft fan
> either, but I like the idea nevertheless), you could even pack the
> whole publish-subscribe functionality into the functor itself.

Delegates are weak compared to C++ libraries that have existed for years. I
still can't fathom why one would implement delegates in such an inflexible
manner as Microsoft did.

> Granted, functors referencing only one function (probably the
> majority in most applications) carry around all the baggage needed to
> reference an arbitrary number of functions, so this approach is not
> very "C++-like" (you only pay for what you use).

Having these function objects reference only one function can also be
considered a good building block for higher-level concepts (e.g., C#-like
delegates, or a more powerful mechanism).

> But there is a huge
> number of C++ applications, where neither performance nor memory
> footprint is an issue and implementation speed is _everything_. I'm
> currently working in such a project and we are using functors for
> publish-subscribe and asynchronous callbacks. I'm glad having chosen
> to implement functors which support equality and chaining. Thanks to
> the many similarities with native function pointers the functors were
> easily introduced and immediately used by all developers, with very
> few questions asked (nobody ever asked about adapting functors like
> std::less or even custom functors).

If you are interested in seeing another approach, please check out the
Signals library at:

It's a signals & slots implementation, which is very similar to a
publisher-subscriber system. It may not be exactly the function pointer
interface that C(++) programmers are accustomed to, but the interface is very
simple and straightforward.


Boost list run by bdawes at, gregod at, cpdaniel at, john at