David Abrahams wrote:
"Matthew Hurd" <matt@finray.net> writes:
Why would I want to do this? I would like to use this approach as a way for inserting an intermediary function. Specifically, I would like to call f<direct>(x,y) and have the direct representation called or f<marshal, destination>(x,y) and have an intermediary serialize the params into a block and send it off on a transport where a representation along the lines of f<marshal, source>(x,y) would accept the block in some infrastructure somewhere else. f<queue_for_processing_in_a_thread_pool>(x,y) fits this model too.
Any thoughts?
I guess my first thought is: "Whaa??? What does any of the above have to do with a named parameters library?"
And then I think: "OK, he wants something that mates the serialization library from Robert Ramey with the new tuples (fusion) from Joel de Guzman".
Conceptually, I think that he wants to serialize a boost::function<>. My advice is "don't bother". I use shared_ptr<Command> for serializeable polymorphic functions. BTW, it is not necessary to serialize/marshal the function object in order to pass it to a thread (pool), only IPC needs marshaling.