David Abrahams said:
> "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.
OK. Thanks for the input. I go from here.
--
William E. Kempf
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
