Boost logo

Boost :

From: Alberto Ganesh Barbati (abarbati_at_[hidden])
Date: 2006-07-14 21:05:27


Dean Michael Berris ha scritto:
> On 7/14/06, Kevin Spinar <spinarkm_at_[hidden]> wrote:
>> On 7/13/06, Dean Michael Berris <mikhailberis_at_[hidden]> wrote:
>>> [snip code]
>> I'm sorry, but I don't see how this is a big advantage over using a
>> std::map<int, boost::function<T> >.
>>
>
> Here's a case which is a significant advantage over std::map<int,
> boost::function<T> > :
>
> [start code]
>
> struct my_validator {
> bool operator () (const std::string & str) {
> return str.size() >= 5;
> }
> };
>
> struct my_router {
> std::string operator() (const std::string & str) {
> std::string temp = "";
> // perform hashing/transformation here
> return temp;
> }
> };
>
> // ...
> dispatcher <void (std::string), std::string, my_validator, my_router> d;
> d["1234"] = void_function_takes_string; // will throw an
> invalid_index<std::string> exception
> d["12345"] = void_function_takes_string; // will map the callback to the hash
> // of "12345" as defined in the router policy
> d["23456"]("my string input"); // if "23456" hashes the same as "12345"
> // then `void_function_takes_string' is called where "my string input"
> // is passed accordingly
>
> [end code]
>
> This is called strategized index validation, and strategized routing
> implementation -- both being concepts that will need much
> documentation. This is documented in the dispatcher.design.dispatcher
> section in the included documentation.
>

Hmmm... I fail to see two things:

1) why would I want/need such features on a 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.

Ganesh


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk