我没有使用任何版本的 MSVC,因此无法根据实际情况检查我的答案,但无论如何这是我的假设:
'boost::promise::promise' : cannot access private member declared in class 'boost::promise'
这表明有人试图访问boost::promise 的私有成员。我们可以得出结论,“某人”不是boost::promise 本身,因为boost::promise 绝对可以访问它自己的私人成员!这意味着行首的标识符boost::promise::promise 必须是相关私有成员的名称(而不是潜在访问者的名称)。
boost::promise::promise 是boost::promise 的一些构造函数 的名称。不幸的是,MSVC 没有告诉我们它是 哪个 构造函数。
boost\thread\detail\thread.hpp(389):
这表明有问题的成员访问权限位于boost::thread 的某个成员中。 thread 必须在某个地方处理boost::promise 类型的对象。这意味着几乎可以肯定,罪魁祸首在您代码的这一行:
boost::thread t(thread_func, boost::move(p));
可能出了什么问题?
好吧,我的假设是基于“将构造函数设为私有”是 C++11 之前的习语,意思是“嘿,不要使用这个构造函数”。 (在 C++11 中,我们改为使用 =delete。)而 boost::promise 是一个只能移动的类型 — 将 =delete 其复制构造函数或在 C++03 中声明其复制构造函数 @ 是合理的987654336@。 (见鬼,它也可能在 C++11 中声明 =delete'd 构造函数 private。为什么不呢,对吧?)
所以假设应该责备复制构造函数,下一个问题是为什么boost::thread 试图访问复制构造函数。我在这里的假设是 boost::move(p) 没有做你认为它做的事情:不知何故,它返回了一个普通的旧左值引用,boost::thread 因此尝试使用 private 复制构造函数进行复制。这可能是由于在一些奇怪的半 C++11 模式下编译造成的——见下文。
修复可能是在严格的 C++03 模式下编译,或者获得一个具有更好 C++11 一致性的编译器,这样您就可以放弃所有这些 Boost hack。 (您可能不应该尝试在 C++11 中使用 boost::thread 和 boost::future,因为 C++11 已经在语言中内置了 std::thread 和 std::future。)
我不是 100% 确定(因为这似乎令人难以置信),但我认为如果你使用 BOOST_NO_CXX11_DELETED_FUNCTIONS 编译但没有使用 BOOST_MOVABLE_BUT_NOT_COPYABLE 类,你可能会遇到这种情况BOOST_NO_CXX11_RVALUE_REFERENCES。至少从阅读 Boost 1.55 中的代码来看是这样的。