Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-10 18:32:24

"William E. Kempf" <wekempf_at_[hidden]> writes:

>> From: David Abrahams <dave_at_[hidden]>
>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>> > It's a tool that allows high-level interfaces to be built. Whether
>> > people will want/need to build their own high-level interfaces is
>> > another story.
>> I think it's a valuable question to ask whether /everyone/ will want
>> to create /the same/ high-level interface ;-). In other words, as
>> long as we have a bunch of low-level thread primitives, I prefer to
>> reduce interface complexity and increase encapsulation unless we can
>> find a specific use for a medium-level interface.
> How about this compromise:


I don't want either of these to have a separate function (operator()
in this case) which initiates the call, for reasons described earlier

My suggestion:

  template <typename R>
  class future
      template <class F, class Executor>
      future(F const& f, Executor const& e)
          : m_pimpl(new async_call<R>(f))

      future(const future<R>& other)
          mutex::scoped_lock lock(m_mutex);
          m_pimpl = other.m_pimpl;

      future<R>& operator=(const future<R>& other)
          mutex::scoped_lock lock(m_mutex);
          m_pimpl = other.m_pimpl;

      R result() const
          return get()->result();

      shared_ptr<async_call<R> > get() const
          mutex::scoped_lock lock(m_mutex);
          return m_pimpl;

      shared_ptr<async_call<R> > m_pimpl;
      mutable mutex m_mutex;

  // Not convinced that this helps, but...
  template <class R>
  R result(future<R> const& f)
      return f.result();

...and I don't care whether async_call gets implemented as part of the
public interface or not, but only because I can't see a compelling
reason to have it yet.

Dave Abrahams
Boost Consulting

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