为什么我们需要d::promise和d::f实现？

Question

我想知道为什么我们需要std:：promise和std:：future？为什么c 11标准将get和set_ value分为两个独立的类std:：future和std:：promise？在这篇文章的回答中，它提到：

它被分成这两个独立的“接口”的原因是为了对“消费者/阅读器”隐藏“写入/设置”功能。

我不明白躲在这里的好处。但是，如果我们只有一个类的“未来”，那不是更简单吗？例如：promise.set_value可以用future.set_value代替。

Answer 1

我将Promise/Future视为异步队列（仅用于保存单个值）。

未来是队列的读取端。promise是队列的写入端。

这两者的用法通常是不同的:生产者通常只是向“队列”写入，而消费者只是从中读取。正如您所提到的，虽然生产者可以读取值，但很少有理由这样做，因此优化特定的操作很少被视为优先事项。

在通常的情况下，生产者产生价值，并将其放入promise中。消费者从未来获得价值。每个“客户机”都使用一个专门用于一个简单任务的简单接口，因此更容易设计和记录代码，并确保（例如）消费者代码不会干扰与产生价值相关的内容（反之亦然）。是的，这样做是可能的，但额外的工作足够多，不太可能发生意外。

Answer 2

promise/future要解决的问题是将值从一个线程引导到另一个线程。它也可以传输异常。

因此，源线程必须有一些可以与之对话的对象，以便将所需的值发送给另一个线程。好吧…谁拥有那个东西？如果源有一个指向目标线程拥有的某个对象的指针，那么源如何知道目标线程是否删除了该对象？也许目标线程不再关心该值；也许有些事情改变了，以至于它决定把你的线掉在地板上，然后忘掉它。

在某些情况下，这是完全合法的代码。

所以现在的问题变成了为什么源不拥有Promise，而只是给目标一个指向它的指针/引用？嗯，这有一个很好的理由：Promise归源线程所有。一旦源线程终止，Promise将被销毁。因此给目标线程留下对已销毁的Promise的引用。

哎呀。

因此，唯一可行的解决方案是拥有两个成熟的对象:一个用于源，一个用于目的地。这些对象共享被传输的值的所有权。当然，这并不意味着他们不能是同一类型；您可以使用类似于< code>shared_ptr的代码

然而，考虑一下当前promise/未来的界面。

promise是不可复制的。您可以移动它，但不能复制它。future也是不可复制的，但未来可以成为可复制shared_future。因此，您可以有多个目标，但只有一个源。

promise只能设置值；它甚至不能把它拿回来future只能获取值；它无法设置它。因此，您有一个非对称接口，它完全适合这个用例。您不希望目标能够设置值，而源能够检索值。这是向后的代码逻辑。

这就是你想要两个物体的原因。你有一个非对称接口，最好用两个相关但独立的类型和对象来处理。