How to remove stl containers?

How will a container object, such as a vector in stl, be destroyed even if they are created on the heap?

EDIT

If the container contains pointers, then how to destroy these pointer objects

+4
source share
12 answers

The STL container of the pointer does NOT clear the data it points to. It will clear only the space holding the pointer. If you want the vector to clear pointer data, you need to use some kind of smart pointer implementation:

{ std::vector<SomeClass*> v1; v1.push_back(new SomeClass()); std::vector<boost::shared_ptr<SomeClass> > v2; boost::shared_ptr<SomeClass> obj(new SomeClass); v2.push_back(obj); } 

When this area ends, both vectors will free their internal arrays. v1 will skip SomeClass, which was created, since only a pointer to it is in the array. v2 will not leak any data.

+18
source

If you have vector<T*> , your code should delete these pointers before deleting the vector: otherwise, this memory has leaked.

Know that C ++ does not do garbage collection, here is an example of why (applications for syntax errors, some time has passed since I wrote C ++):

 typedef vector<T*> vt; ⋮ vt *vt1 = new vt, *vt2 = new vt; T* t = new T; vt1.push_back(t); vt2.push_back(t); ⋮ delete vt1; 

The last line ( delete vt1; ) clearly should not delete the pointer that it contains; after all, it is also in vt2. The way it is. And not one of them will remove vt2 .

(If you need a vector type that deletes destruction pointers, that type could certainly be written. It probably was. But beware of delete pointers that someone else is holding a copy of.)

+5
source

When the vector goes out of scope, the compiler issues a call to its destructor, which, in turn, frees the allocated memory on the heap.

+2
source

This is somewhat wrong. A vector, like most STL containers, consists of two logical parts.

  • vector instance
  • actual base array implementation

While configurable, # 2 almost always lives on the heap. # 1, however, can live on the stack as well as on the heap, it only depends on how it was allocated. For instance,

 void foo() { vector<int> v; v.push_back(42); } 

In this case, part number 1 lives on the stack.

Now how is # 2 destroyed? When the first part of the vector is destroyed, it will also destroy the second part. This is done by removing the base array inside the destructor of the vector class.

+2
source

If you store pointers in STL container classes, you must manually delete them before the object is destroyed. This can be done by going through the entire container and deleting each element or using some class of smart pointers. However, do not use auto_ptr, as this simply does not work with containers.

A good side effect of this is that you can store several containers of pointers in your program, but only those objects that belong to one of these containers, and you only need to clear this one container.

The easiest way to remove pointers:

 for (ContainerType::iterator it(container.begin()); it != container.end(); ++it) { delete (*it); } 
+2
source

Use either smart pointers inside the vector, or use boost ptr_vector. It will automatically release the selected objects inside it. There are also cards, sets, etc.

http://www.boost.org/doc/libs/1_37_0/libs/ptr_container/doc/ptr_vector.html and the main site: http://www.boost.org/doc/libs/1_37_0/libs/ptr_container/doc /ptr_container.html

+2
source

Like any other object on the heap, it must be destroyed manually (with deletion).

0
source

To answer your first question:

There is nothing special about STL classes (hopefully). They function just like other template classes. That way, they will not be automatically destroyed if they are allocated on the heap because C ++ has no garbage on them (unless you say this with some fancy autoptr business or something else). If you put it on the stack (without a new one), it will most likely be controlled by C ++ automatically.

For your second question, here is a very simple ArrayOfTen class to demonstrate the basics of typical memory management in C ++:

 /* Holds ten Objects. */ class ArrayOfTen { public: ArrayOfTen() { m_data = new Object[10]; } ~ArrayOfTen() { delete[] m_data; } Object &operator[](int index) { /* TODO Range checking */ return m_data[index]; } private: Object *m_data; ArrayOfTen &operator=(const ArrayOfTen &) { } }; ArrayOfTen myArray; myArray[0] = Object("hello world"); // bleh 

Basically, the ArrayOfTen class stores an internal array of ten Object elements on the heap. When a new [] is called in the constructor, space is allocated on the heap for ten objects and ten objects are created. Similarly, when delete [] is called in the destructor, ten objects are deconstructed, and then the previously allocated memory is freed.

For most (all?) STL types, resizing is done behind the scenes to make sure there is enough memory to fit your elements. The above class only supports arrays of ten objects. This is basically a very limited typedef of the object [10].

0
source

To remove the marked items, I wrote a simple functor:

 template<typename T> struct Delete { void operator()( T* p ) const { delete p; } }; std::vector< MyType > v; // .... std::for_each( v.begin(), v.end(), Delete<MyType>() ); 

But you should discard shared pointers when the contents of a vector should be ... ehm ... shared. Yes.

0
source

Standard STL containers place a copy of the source object in the container using the copy constructor. When a container is destroyed, the destructor of each object in the container is also called to safely destroy the object.

Pointers are treated the same way. The thing about pointers is POD data. A copy constructor for a pointer is just a copy of the address, and the POD data does not have a destructor. If you want the container to control the pointer, you need to:

  • Use a smart pointer container. (e.g., a generic pointer).
  • Use the ppt boost container.

I prefer container pointer:
The pointer containers are the same as the STL containers, except that you put pointers in them, but then the container becomes the property of the object that the pointer points to, and thus frees the object (usually by deleting it) when the container is destroyed.

When you access the members of the ptr container, they are returned via the link, so they behave exactly like a standard container for use in standard algorithms.

 int main() { boost::ptr_vector<int> data; data.push_back(new int(5)); data.push_back(new int(6)); std::cout << data[0] << "\n"; // Prints 5. std::cout << data[1] << "\n"; // Prints 6. } // data deallocated. // This will also de-allocate all pointers that it contains. // by calling delete on the pointers. Therefore this will not leak. 

It should also be noted that smart pointers in a container are a valid alternative, unfortunately std :: auto_ptr <> is not a valid smart pointer choice for this situation.

This is because the STL containers assume that the objects they contain can be copied, unfortunately std :: auto_ptr <> cannot be copied in the traditional sense, since it destroys the original value on the copy, and therefore copy source cannot be Set.

0
source

STL containers are similar to any other objects if you create an instance created on the stack:

 std::vector<int> vec(10); 

Like any other stack variable, it only lives in the region of the function in which it is defined, and it does not need to be deleted manually. The destructor of STL containers will invoke the destructor of all elements in the container.

Storing pointers in a container is a dizzying problem. Since pointers do not have destructors, I would say that you will never want to enter the source pointers in the STL container. It will be very difficult to do this in a safe way, you will have to lure your code with try {} finally {} blocks to ensure that the contained pointers are always freed.

So what should you put in containers instead of raw pointers? +1 jmucchiello to boost boost :: shared_ptr. boost :: shared_ptr is safe to use in STL containers (unlike std :: auto_ptr). It uses a simple link counting mechanism and is safe to use in data structures that do not contain loops.

What do you need for data structures containing loops? In this case, you probably want to finish garbage collection, which essentially means using a different language, such as Java. But this is another discussion .;)

0
source

All Articles