Destructors in STL?
-
Hi I see that all stl components have destructors. string s; s.~string(); But i know that we don't need to delete stl componenets.I read all stl components automatically delete themself.Is this wrong? If true what is the function of destructors in STL? Thanks...
-
Hi I see that all stl components have destructors. string s; s.~string(); But i know that we don't need to delete stl componenets.I read all stl components automatically delete themself.Is this wrong? If true what is the function of destructors in STL? Thanks...
How do you expect STL components to magically delete themselves ? Cleaning up after themselves is what C++ classes have destructors for.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
Hi I see that all stl components have destructors. string s; s.~string(); But i know that we don't need to delete stl componenets.I read all stl components automatically delete themself.Is this wrong? If true what is the function of destructors in STL? Thanks...
say u have vector in such case the vector will delete the pointers but the memory referred by the pointers.So it leads to memory leak
never say die
-
Hi I see that all stl components have destructors. string s; s.~string(); But i know that we don't need to delete stl componenets.I read all stl components automatically delete themself.Is this wrong? If true what is the function of destructors in STL? Thanks...
sawerr wrote:
But i know that we don't need to delete stl componenets
I don't think you quite understand C++ fundamentals. STL classes (string, vector, list, map, etc) all allocate memory on the heap to store whatever data you are throwing at them. string, for example, allocates an array of characters. As you fill up that array, it evaluates if it needs to allocate a bigger buffer, etc. All that is handled for you. The destructor cleans up that heap memory. When you write:
void f() { string s; }
s is allocated on the stack. At the end of the scope (in this case, when the function returns), s's destructor is called, which cleans up anything s had allocated. If you were to write this:
void f() { string* s = new string; }
you would have a memory leak (not good!).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
How do you expect STL components to magically delete themselves ? Cleaning up after themselves is what C++ classes have destructors for.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
say u have vector in such case the vector will delete the pointers but the memory referred by the pointers.So it leads to memory leak
never say die
If you have a vector of pointers to dynamically created objects, you must explicitly delete those objects before the vector goes out of scope: using std::wcout; using std::endl; using std::vector; class Foo { public: Foo(int index) : m_index(index) { wcout << L"Creating Foo #" << m_index << endl; } ~Foo() { wcout << L"Destroying Foo #" << m_index << endl; } private: int m_index; }; int _tmain(int argc, _TCHAR* argv[]) { vector pFooList; for (int i = 0; i < 10; ++i) { pFooList.push_back(new Foo(i)); } for (int i = 0; i < 10; ++i) { delete pFooList[i]; } return 0; } -- modified at 0:01 Saturday 12th August, 2006
-
If you have a vector of pointers to dynamically created objects, you must explicitly delete those objects before the vector goes out of scope: using std::wcout; using std::endl; using std::vector; class Foo { public: Foo(int index) : m_index(index) { wcout << L"Creating Foo #" << m_index << endl; } ~Foo() { wcout << L"Destroying Foo #" << m_index << endl; } private: int m_index; }; int _tmain(int argc, _TCHAR* argv[]) { vector pFooList; for (int i = 0; i < 10; ++i) { pFooList.push_back(new Foo(i)); } for (int i = 0; i < 10; ++i) { delete pFooList[i]; } return 0; } -- modified at 0:01 Saturday 12th August, 2006
Use auto_ptr<> will delete them for you #include using std::wcout; using std::endl; using std::vector; class Foo { public: Foo(int index) : m_index(index) { wcout << L"Creating Foo #" << m_index << endl; } ~Foo() { wcout << L"Destroying Foo #" << m_index << endl; } private: int m_index; }; int _tmain(int argc, _TCHAR* argv[]) { vector< std::auto_ptr< Foo* > > pFooList; for (int i = 0; i < 10; ++i) { pFooList.push_back( std::auto_ptr< Foo* >(new Foo(i))); } /* no need to delete, std::auto_ptr takes care if it for you. //see #include for (int i = 0; i < 10; ++i) { delete pFooList[i]; } */ return 0; }
:cool: -
Use auto_ptr<> will delete them for you #include using std::wcout; using std::endl; using std::vector; class Foo { public: Foo(int index) : m_index(index) { wcout << L"Creating Foo #" << m_index << endl; } ~Foo() { wcout << L"Destroying Foo #" << m_index << endl; } private: int m_index; }; int _tmain(int argc, _TCHAR* argv[]) { vector< std::auto_ptr< Foo* > > pFooList; for (int i = 0; i < 10; ++i) { pFooList.push_back( std::auto_ptr< Foo* >(new Foo(i))); } /* no need to delete, std::auto_ptr takes care if it for you. //see #include for (int i = 0; i < 10; ++i) { delete pFooList[i]; } */ return 0; }
:cool::omg: Unfortunately, that should not compile! According to the book, "The C++ Standard Library: A Tutorial and Reference" by Nicolai M. Josuttis, I quote: auto_ptrs don't meet the requirements for container elements. An auto_ptr does not meet one of the most fundamental requirements for elements of standard containers. That is, after a copy or an assignment of an auto_ptr, source and sink are not equivalent. In fact, when an auto_ptr is assigned or copied, the source auto_ptr gets modified because it transfers its value rather than copying it. So, you should not use an auto_ptr as an element of a standard container. ... However, boost::shared_ptr can be used with containers! See: http://www.boost.org/libs/smart_ptr/shared_ptr.htm[^] George -- modified at 17:52 Thursday 17th August, 2006
-
:omg: Unfortunately, that should not compile! According to the book, "The C++ Standard Library: A Tutorial and Reference" by Nicolai M. Josuttis, I quote: auto_ptrs don't meet the requirements for container elements. An auto_ptr does not meet one of the most fundamental requirements for elements of standard containers. That is, after a copy or an assignment of an auto_ptr, source and sink are not equivalent. In fact, when an auto_ptr is assigned or copied, the source auto_ptr gets modified because it transfers its value rather than copying it. So, you should not use an auto_ptr as an element of a standard container. ... However, boost::shared_ptr can be used with containers! See: http://www.boost.org/libs/smart_ptr/shared_ptr.htm[^] George -- modified at 17:52 Thursday 17th August, 2006
#include #include #include using std::wcout; using std::endl; using std::vector; using boost::shared_ptr; class Foo { public: Foo(int index) : m_index(index) { wcout << L"Creating Foo #" << m_index << endl; } ~Foo() { wcout << L"Destroying Foo #" << m_index << endl; } private: int m_index; }; int _tmain(int argc, _TCHAR* argv[]) { vector< shared_ptr > pFooList2; for (int i = 0; i < 10; ++i) { shared_ptr sptr(new Foo(i)); pFooList2.push_back(sptr); } return 0; }
-
Use auto_ptr<> will delete them for you #include using std::wcout; using std::endl; using std::vector; class Foo { public: Foo(int index) : m_index(index) { wcout << L"Creating Foo #" << m_index << endl; } ~Foo() { wcout << L"Destroying Foo #" << m_index << endl; } private: int m_index; }; int _tmain(int argc, _TCHAR* argv[]) { vector< std::auto_ptr< Foo* > > pFooList; for (int i = 0; i < 10; ++i) { pFooList.push_back( std::auto_ptr< Foo* >(new Foo(i))); } /* no need to delete, std::auto_ptr takes care if it for you. //see #include for (int i = 0; i < 10; ++i) { delete pFooList[i]; } */ return 0; }
:cool:dfields326 wrote:
Use auto_ptr<> will delete them for you
Containers of auto_ptr's is a BIG No-No! It will compile on some older compilers, but it will not do anything close to what you expect it to. It won't even compile on newer compilers.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac