Boost logo

Boost :

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2006-07-14 21:51:43

On 7/15/06, Alberto Ganesh Barbati <abarbati_at_[hidden]> wrote:
> 1) why would I want/need such features on a dispatcher?

This is a good question, and the answer would be "it depends on the use case".

For index validation, an example would be if you were taking runtime
input and using them as indexes, and you want to enforce that indexes
be of a certain kind (or setting rules on what valid indexes should
be). This would come in handy in case you were registering dynamically
loaded functions to runtime values as indexes and want to make sure
that the indexes conform to some convention (in cases where you're
implementing protocol handlers, and the schema is dynamic like XML).

For index manipulation/hashing/transformation/routing the case would
be for "normalizing" the valid indexes (or even the invalid indexes).
That means trivial stuff like rounding up numbers, generating an md5
hash, doing case normalization, and the likes can be decoupled from
the actual dispatching.

Of course, both of these are optional, and there are default "dumb"
routing and validation strategies that are by default implemented by
the dispatcher

> 2) what it is the relationship between such features and the dispatcher?
> I mean, index validation and routing are (to me at least) two concepts
> completely unrelated to dispatching, so IMHO it would make much more
> sense to have a generic container that could store any value type, not
> only functions. Once you have such container, you can make a decent
> dispatcher by just putting boost::functions in it.

Think of it as "message routing" if "dispatching" conjures up a lot of
different things for you. For me at least, this is how I understand
how a dispatcher works:

Someone (client code) refers to a person (dispatcher) and asks "can
you please get me <index>?" -- the person (dispatcher) is trained to
see if <index> is a valid index (validation) and normalizes/transforms
the index (routing) to pull up the correct object/function requested.

As far as I understand it, if you don't need the validation and
routing, then you don't need the dispatcher -- but in cases that you
do need that, or a runtime switch replacement, then it should come in

The goal of the dispatcher is to facilitate the registration and
dispatching (or calling) of runtime functions, and providing a
dynamically reprogrammable interface for such a facility. For certain
problem domains, this appeals as a simple and extensible solution --
in other cases, it might be overkill.


Dean Michael C. Berris
C/C++ Software Architect
Orange and Bronze Software Labs
Mobile: +639287291459
Email: dean [at] orangeandbronze [dot] com

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