STL vector on heap?

Hello,

If I create an STL vector, is the memory assigned on the heap or the stack?

For example:

Code:

---

#include <vector>

int main()
{
    std::vector<int> my_vector(3);
    my_vector[0] = 1;
    my_vector[1] = 10;
    my_vector[2] = 100;

    return 0;
}

---

Are the contents of "my_vector" on the heap, or the stack? I haven't declared the vector using the "new" keyword, so for a normal object, it would be created on the stack. But because a vector is a STL object, does it behave differently?

If the vector is created on the heap, then how do I free the memory? Do I follow the standard approach:

Code:

---

// Free up the space allocated to the vector
delete &my_vector;
// Or perhaps this?
delete my_vector;

---

If your answer to the first part is the the vector is created on the stack, then how do I in fact create it on the heap? Do I use :

Code:

---

std::vector<int>* my_vector = new std::vector<int>(3);

---

Thanks for the help :)

Quote:

---

Originally Posted by karnavor

Are the contents of "my_vector" on the heap, or the stack? I haven't declared the vector using the "new" keyword, so for a normal object, it would be created on the stack. But because a vector is a STL object, does it behave differently?

---

Well, my_vector is a local variable, so the memory for it is presumably allocated from the stack. However, the memory for the contents of my_vector depends on the allocator. In this case the default allocator is used, so the memory for the contents presumably allocated from the heap.

The vector will perform memory management of its contents. When it goes out of scope, it is destroyed, and its contents are destroyed as well.

The vector itself is on the stack. Internally it will use heap memory, but you don't need to worry about that because it hides the details from you. Nothing special is required to release that memory, the vector will do it automatically when it is destroyed (goes out of scope on the stack).

If you put something on the stack, you should be able to treat it as a completely stack-based object for all intents and purposes, regardless of what it does internally. Any object which doesn't follow this rule is probably poorly designed.

Ah I see, so I can treat it like a normal stack variable. However, suppose that my vector contains an array of pointers to objects, which themselves are allocated on the heap. In this case, when my vector goes out of scope and it is deleted, will the vector deconstructor free up all these objects? Or will I have to do that manually?

Thanks.

The vector knows nothing about the type it is containing. If you make a vector<Object*> and each entry is heap-allocated, you'll need to free them manually.

On the other hand, there are some ways to get around this requirement. You could use a vector< shared_ptr<Object> > (both Boost and TR1 have shared_ptr implementations), or you could use a boost::ptr_vector<Object> which does much the same thing internally.

Quote:

---

Originally Posted by karnavor

However, suppose that my vector contains an array of pointers to objects, which themselves are allocated on the heap. In this case, when my vector goes out of scope and it is deleted, will the vector deconstructor free up all these objects? Or will I have to do that manually?

---

The basic rule to remember is this:
For every call you make to 'new' you have to make one call to 'delete'.
For every call you make to 'new[]' you have to make one call to 'delete[]'.

Trying to understand this.

In other words, if I create a local vector of 100,000 elements, then 100,000 STL vector elements are pushed onto my stack. So if the STL vector overhead for each element is, say, 12 bytes, then I have consumed 12x100,000 = 1.2MB of stack for this, just for the overhead and management
of the STL vector itself.

But if each of those elements is itself a 50 byte string, THAT storage comes from the heap because the STL vector class allocates that under the covers?

That makes sense to me. Is this how it really works?

The only thing which *always* goes onto the stack is sizeof(vector<T>) worth of bytes, interpreted and controlled entirely by the vector implementation. As always with sizeof, this value is a compile-time constant and does not depend on the (runtime-determined) number of elements the vector can hold.

Where all the bytes for holding those elements come from depends on what allocator the vector was constructed with. The default allocator puts the elements themselves on the heap, but it's possible to substitute an allocator which uses the stack instead (with some caveats). That's nontrivial though.

So if you construct:
vector<string> myvec(50,string(10));

Then sizeof(vector<string>) bytes go on the stack, (at least) 50*sizeof(string) bytes go on the heap (controlled by the vector), and (at least) 10 further bytes go on the heap for each of the 50 strings.

I say "at least" because STL containers are allowed to allocate more memory than they currently need, and in the case of vectors and strings, this is actually a very good thing. By constructing the objects in this *particular* way it's unlikely much extra space will be reserved, but as soon as you do a push_back or a string operator+=, all bets are off.

Quote:

---

Originally Posted by mmagliaro

Trying to understand this.

In other words, if I create a local vector of 100,000 elements,

---

Dynamic allocation is still done, no matter how you placed those elements in the vector.

Code:

---

#include <vector>

int main()
{
  std::vector<int> IntVect;
  for (int i = 0; i < 1000000; ++i )
    IntVect.push_back( i );
}

---

The vector is a local variable. Local variables go whereever all local variables go. A vector<T> is no different than an int, double, float, char, or any other type when it comes to local variables.

However, the call to push_back() will invariably call the allocator to allocate space for the elements from the free-store.

Regards,

Paul McKenzie