shared-ptr

How to view the internal data of a smart pointer inside gdb?

由 冷暖自知 提交于 2019-12-01 04:23:35
I've got test program like below: #include<memory> #include<iostream> using namespace std; int main() { shared_ptr<int> si(new int(5)); return 0; } Debug it: (gdb) l 1 #include<memory> 2 #include<iostream> 3 using namespace std; 4 5 int main() 6 { 7 shared_ptr<int> si(new int(5)); 8 return 0; 9 } 10 (gdb) b 8 Breakpoint 1 at 0x400bba: file testshare.cpp, line 8. (gdb) r Starting program: /home/x/cpp/x01/a.out Breakpoint 1, main () at testshare.cpp:8 8 return 0; (gdb) p si $1 = std::shared_ptr (count 1, weak 0) 0x614c20 It only prints out the pointer type information of si , but how to get the

C++ static classes & shared_ptr memory leaks

由 [亡魂溺海] 提交于 2019-12-01 04:06:50
I can't understand why does the following code produce memory leaks (I am using boost::shared_ptr with static class instance). Could someone help me? #include <crtdbg.h> #include <boost/shared_ptr.hpp> using boost::shared_ptr; #define _CRTDBG_MAP_ALLOC #define NEW new(_NORMAL_BLOCK, __FILE__, __LINE__) static struct myclass { static shared_ptr<int> ptr; myclass() { ptr = shared_ptr<int>(NEW int); } } myclass_instance; shared_ptr<int> myclass::ptr; int main() { _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF | _CRTDBG_CHECK_ALWAYS_DF | _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG)); return 0;

Will a shared_ptr automatically free up memory?

由 北城以北 提交于 2019-12-01 03:41:36
问题 I need to use a shared_ptr here because I can't change the API. Foo1 *foo1 = new Foo1(...); shared_ptr<Foo2> foo2(foo1); Is the shared_ptr here going to handle freeing the memory used by foo1? If I understand correctly, I shouldn't have to call delete on foo1 correct? 回答1: Yes. You are correct, but the correct way to initialise foo2 is: std::shared_ptr<Foo2> foo2 = std::make_shared<Foo1>(); Herb Sutter discusses the reasons why you should use std::make_shared<>() here: https://herbsutter.com

Problems with shared_ptr<T[]> wrapping a dynamic array

由 孤者浪人 提交于 2019-12-01 03:12:00
问题 I wanted to replace some raw pointers in my class with a std::shared_ptr so that I don't have to worry when I create copies of that class. But the raw pointers point to a dynamic array. Using a shared_ptr with dynamic arrays is possible when you give it a custom deleter, e. g. default_delete<T[]> . But I get a big error list as soon as I try to assign a new value to that field, even on construction. Here's a minimal code sample: #include <memory> #include <cstddef> using namespace std;

C++: auto_ptr + forward declaration?

由 北城余情 提交于 2019-12-01 02:58:42
I have a class like this: class Inner; class Cont { public: Cont(); virtual ~Cont(); private: Inner* m_inner; }; in the .cpp, the constructor creates an instance of Inner with new and the destructor delete s it. This is working pretty well. Now I want to change this code to use auto_ptr so I write: class Inner; class Cont { public: Cont(); virtual ~Cont(); private: std::auto_ptr<Inner> m_inner; }; Now, the constructor initialized the auto_ptr and the destructor does nothing. But it doesn't work. the problem seem to arise when I'm instantiating this class. I get this warning: warning C4150:

What is the meaning of this piece of Standardese about shared_ptr's use_count()?

由 与世无争的帅哥 提交于 2019-12-01 02:07:51
While trying to wrap my head around the problem shown in this question I found myself stuck on the following sentence from [util.smartptr.shared]/4: [...] Changes in use_count() do not reflect modifications that can introduce data races. I don't understand how I should read that, and what conclusions shall I draw. Here are a few interpretations: Invoking use_count() does not introduce data races (but this should be guaranteed by the const -ness of that function alone, together with the corresponding library-wide guarantees) The value returned by use_count() is not influenced by ("does not

How to view the internal data of a smart pointer inside gdb?

由 a 夏天 提交于 2019-12-01 01:59:10
问题 I've got test program like below: #include<memory> #include<iostream> using namespace std; int main() { shared_ptr<int> si(new int(5)); return 0; } Debug it: (gdb) l 1 #include<memory> 2 #include<iostream> 3 using namespace std; 4 5 int main() 6 { 7 shared_ptr<int> si(new int(5)); 8 return 0; 9 } 10 (gdb) b 8 Breakpoint 1 at 0x400bba: file testshare.cpp, line 8. (gdb) r Starting program: /home/x/cpp/x01/a.out Breakpoint 1, main () at testshare.cpp:8 8 return 0; (gdb) p si $1 = std::shared_ptr

C++ static classes & shared_ptr memory leaks

由 心不动则不痛 提交于 2019-12-01 01:20:19
问题 I can't understand why does the following code produce memory leaks (I am using boost::shared_ptr with static class instance). Could someone help me? #include <crtdbg.h> #include <boost/shared_ptr.hpp> using boost::shared_ptr; #define _CRTDBG_MAP_ALLOC #define NEW new(_NORMAL_BLOCK, __FILE__, __LINE__) static struct myclass { static shared_ptr<int> ptr; myclass() { ptr = shared_ptr<int>(NEW int); } } myclass_instance; shared_ptr<int> myclass::ptr; int main() { _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM

Initialization of shared_ptr<T> from unique_ptr<T[]>

由 孤街浪徒 提交于 2019-12-01 01:08:00
问题 [Followup to this question] I've been dealing a little bit with smart pointers to c-style arrays recently. I ultimately wound up doing the recommended thing and using smart pointers to vectors instead, but during that period, I got a bit of advice: don't use a shared_ptr<T> object to manage an array initially made with make_unique<T[]> because it won't call delete[] but rather delete . This didn't seem logical to me, and I checked both Coliru and the Standard: This code: #include <iostream>

shared_ptr and slicing

由 送分小仙女□ 提交于 2019-12-01 00:17:01
问题 Someone I worked with once said that shared_ptr was unsafe and would slice when casting from a derived class to a base class (i.e. upcasting). For example if there were 2 classes A and B where B derived from A, then shared_ptr<A> a(new B) would slice. I pointed him to http://www.boost.org/doc/libs/1_43_0/libs/smart_ptr/shared_ptr.htm where it says shared_ptr<T> can be implicitly converted to shared_ptr<U> whenever T* can be implicitly converted to U* . implied that it's safe to use in those
订阅 shared-ptr