"William E. Kempf" <[EMAIL PROTECTED]> writes:
>> From: David Abrahams <[EMAIL PROTECTED]>
>> "Peter Dimov" <[EMAIL PROTECTED]> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
