On 18/07/06, Sohail Somani <s.somani@fincad.com> wrote:
I just don't see the point, except as an academic exercise
I used a similar technique when I wrote a subset of some of Kevlin Henney's threading concepts [1]. I wanted to extend it so exceptions could be propagated from the thread function to the calling thread. The client code looked like this : // code begins... std::string my_function(); joiner<std::string> joiner = thread(my_function, catch_<std::runtime_error, my_app_specific_error>()); // parallel work here std::string result = joiner(); // ...ends joiner::operator() may throw std::runtime_error, my_app_specific_error, or std::bad_exception if the exception could not be mapped. Of course exceptions are sliced, but support could be added for cloning if the exception hierarchy supported it (through ADL perhaps). Anyway, I make use of it quite a bit and I've never found the slicing to be a problem - typically you know what you expect to catch So I can see at least one non-academic use for it. Sam [1] http://www.two-sdg.demon.co.uk/curbralan/papers/accu/MoreC++Threading.pdf