如图here,std::unique_ptr有两个用于空指针的constexpr构造函数:constexprunique_ptr();constexprunique_ptr(nullptr_t);我对这两个构造函数有两个问题:为什么我们需要两个？我们不能只声明一个:constexprunique_ptr(nullptr_t=nullptr);constexpr真的有用吗？我尝试在我的代码中这样做，但它没有编译(g++6.1.0，-std=c++14):constexprstd::unique_ptrp;//error:thetype'conststd::unique_ptr'ofcon

无论如何我可以向std::shared_ptr的删除器发送参数吗？感觉像:std::shared_ptrmyA(a,myDeleter(a,5));myDeleter有这个签名:voidmyDeleter(A*a,inti)(显然上面的语法是错误的，但只是为了强调我需要我的删除器来接受额外的参数。) 最佳答案 您可以在将删除器的第二个参数作为删除器传递之前std::bind:autodeleter=std::bind(myDeleter,std::placeholders::_1,5);std::shared_ptrmyA(a,de

当我尝试std::move或std::make_unique时，尝试在union中使用unique_ptr会给我一个段错误。#include#includeunionmyUnion{struct{std::unique_ptrupFloat;}structUpFloat;struct{std::unique_ptrupInt;}structUpInt;myUnion(){}~myUnion(){}};structmyStruct{intx;myUnionnum;};intmain(){myStructaStruct,bStruct;aStruct.x=1;bStruct.x=2;aut

我玩弄了一些流，但无法理解以下内容。这里我们有一个基本的ostreamptr，它设置为不同的输出流，无论是cout、cerr还是file。//ostreamptrstd::ostream*outstream;//setoutputostreamvoidsetOutput(std::ostream&os){outstream=&os;}//writemessagetoostreamvoidwriteData(conststd::string&msg){*outstream以上内容完美运行，展示了c++iostream实现的强大功能。完美的。但是，由于setOutput是通过引用设置的，因

我读过weak_pointers可以用来打破循环引用。考虑下面的循环引用示例structA{boost::shared_ptrshrd_ptr;};boost::shared_ptrptr_A(boost::make_shared());boost::shared_ptrptr_b(boost::make_shared());ptr_A->shrd_ptr=ptr_b;ptr_b->shrd_ptr=ptr_A;以上是循环引用的例子，我想知道如何破解上面使用weak_ptr的循环引用？更新:根据收到的建议，我提出了以下建议:structA{boost::weak_ptrwk_ptr;}

我可以用NULL值初始化shared_ptr吗？boost::shared_ptrs_obj(NULL);如果没有，那怎么办？ 最佳答案 默认构造会为您执行此操作:templateclassshared_ptr{public:explicitshared_ptr(T*p=0):px(p){//Snip}//...private:T*px;//containedpointercount_type*pn;//ptrtoreferencecounter}; 关于c++-将boost::shar

如果我声明一个临时自动删除的字符缓冲区使用std::auto_ptrbuffer(newchar[n]);然后当缓冲区超出范围时，缓冲区会被自动删除。我会假设缓冲区是使用delete删除的。但是缓冲区是使用new[]创建的，所以严格来说应该使用delete[]删除缓冲区。这种不匹配可能导致内存泄漏的可能性有多大？ 最佳答案 对用new[]分配的指针调用delete的行为是undefined.如您所料，auto_ptrdoescalldelete当智能指针超出范围时。您需要担心的不仅仅是内存泄漏——崩溃和其他奇怪的行为也是可能的。如果

有人能用几句简洁的话总结一下如何boostshared_from_this()应该使用智能指针，特别是从使用绑定(bind)函数在io_service中注册处理程序的角度来看。编辑:一些回复要求提供更多背景信息。基本上，我正在寻找“陷阱”，即人们使用这种机制观察到的反直觉行为。 最佳答案 我遇到的最大“陷阱”是从构造函数调用shared_from_this是非法的。这直接遵循这样的规则:对象的shared_ptr必须存在才能调用shared_from_this。 关于c++-boosts

C++17引入了std::shared_mutex和std::scoped_lock。我现在的问题是，当它作为参数传递时，scoped_lock将始终以独占(写入器)模式锁定共享互斥锁，而不是在共享(读取器)模式下。在我的应用程序中，我需要使用来自对象src的数据更新对象dst。我想锁定src共享和dst独占。不幸的是，如果同时调用另一个带有src和dst切换的更新方法，这可能会导致死锁。所以我想使用std::scoped_lock的花哨的死锁避免机制。我可以使用scoped_lock在独占模式下同时锁定src和dst，但是这种不必要的严格锁定会在其他地方产生性能回退。但是，似乎可以将

似乎Boost的shared_mutex是非递归的..周围有吗？(没有重新实现整个东西) 最佳答案 看看thisthread这个excellentexplanation为什么shared_mutex通常是个坏主意。因此，如果您不同意recursive_mutex也是个坏主意，请在没有任何shareiness的情况下使用它，因为它不会给您带来任何性能提升。您将收到更简洁的代码，无需任何重大更改。当许多线程经常读取数据而很少修改数据时，我尝试在我的项目中使用shared_mutex来锁定竞争激烈的map。收到了更差的性能结果