使用shared_ptr<void>代替void*可以解决声明周期管理的问题。shared_ptr有足够的类型信息以了解如何正确销毁它指向的对象。但是std::shared_ptr和void*一样不能解决类型安全的问题。 最后在使用了shared_ptr<void>在SDK内部进行类型强转时报错: /Library/android-ndk-r17c/sources/cxx-stl/llvm-libc++/include/memor...
上面的代码可以使用shared_ptr来改写,更简单: #include<memory> //使用shared_ptr需要包含这个头文件 using namespace std; void g(void){ shared_ptr<int> ptr = make_shared<int>();//手动申请一个堆上的无名int变量,交给智能指针对象ptr来管理 int b; //这里无须手动释放ptr指向的内存,ptr的析构函数会...
1.2 为什么不用shared_ptr<void> 使用shared_ptr<void>代替void*可以解决声明周期管理的问题。shared_ptr有足够的类型信息以了解如何正确销毁它指向的对象。 structday{ // ...things... std::shared_ptr<void> user_data; }; structmonth{ std::vector<day> days; std::shared_ptr<void> user_data; };...
一句话,任何类对象资源都可以被std::shared_ptr<void>接管,并且在离开其作用域,会自动调用其析构函数。 虚析构函数与shared_ptr的火花 首先,将FakeFoo改写为继承自Foo类 class Foo { public: Foo() { cout << "Foo()" << endl; } ~Foo() { cout << "~Foo()" << endl; } }; class FakeFoo...
shared_ptr<void> vptr = shared_ptr<Foo>(newFoo);return0; } 输出: Foo()~Foo() 与第一段代码中类似,不过把void*换成了std::shared_ptr<void>,那么shared_ptr<void>为什么能够调用到正确的析构函数呢?一定是shared_ptr里面搞了什么鬼。 std::shared_ptr<void>为啥能正常工作 ...
我有一些关于为什么可行的想法,这与为G ++实现的std :: shared_ptrs的内部有关。由于这些对象将内部指针与计数器包装在一起,因此从std::shared_ptr<test>到std::shared_ptr<void>的转换可能不会妨碍析构函数的调用。这个假设正确吗? 当然还有一个更重要的问题:这是否可以保证按标准运行,或者可能进一步更改std ...
您有责任确保std::shared_ptr<void>实际上指向T类型的对象。否则，使用std::static_pointer_cast<T>...
先看一下两个shared_ptr指针互相引用导致的资源释放失败的例子: #include<iostream>#include<memory>#include<string>usingnamespacestd;classB;classA{public:shared_ptr<B>pb_;~A(){cout<<"A delete\n";}};classB{public:shared_ptr<A>pa_;~B(){cout<<"B delete\n";}};voidfun(){shared_ptr<B>...
void deleter(vector<int> *p) { delete[] p; cout << "deleter called" << endl; } int main() { shared_ptr<vector<int> > p(new vector<int>[12], deleter); return 0; } 这里我们自定义了 deleter() 函数用于释放与 p 绑定的指针,并且把它作为第二个参数传递给 shared_ptr 的构造函数。现...