|
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