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:

<snip>

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
  {
  public:
      template <class F, class Executor>
      future(F const& f, Executor const& e)
          : m_pimpl(new async_call<R>(f))
      {
          (*get())();
      }

      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();
      }

  private:
      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
www.boost-consulting.com

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