stl containers allocation in heap or stack?

Hi
I am new to stl.
I see that we don't need to delete our containers
For example:
vector <char> vec;
But why?
Here, Does vec allocate in heap or stack by default.I heard that Although we don't create vec without new , it is allocated in heap and automatically delete it.Is this true?
If true i tried this:
vector <char>* vec = new vector<char>;
delete vec;
it doesn't give me error.Here this mustn't work.Am i wrong?

I looked to google, there are so many things about stl but i can't find explanation about relationship between stl containers and heap,stack allocation(or new ,delete).In what circumstances are stl containers allocated in heap or stack.And In what circumstances do we need to delete our containers?

Can you please explain me.

Thanks...

Depends on the implementation, but yes for most cases, I guess.
STL containers are dynamically allocated and automagically managed.

Quote:

---

Originally Posted by sawer

vector <char>* vec = new vector<char>;
delete vec;
it doesn't give me error.Here this mustn't work.Am i wrong?

---

Of course it doesn't give you an error. You are defining vec as a pointer to a vector of chars.

Would defining vec as a pointer to an allocated array of chars give you an error? It wouldn't :)

When you use:

Code:

---

vector<char> vec;

---

the vector object is a local variable placed on the stack. However, the vector usually uses heap-based memory internally to store whatever you put into that vector.

Notice the difference between where the STL container instance is allocated, and where it stores the objects it contains.

BTW, in most cases you shouldn't care where the STL container stores its stuff internally, since that is an implementation detail. Just use the stack based vector instance like above and let it do the dirty work.

The whole point of it is that you don't have to do any dynamic memory allocation.
You can just use

Code:

---

vector<char> vec;

---

in every case.
If you declare it inside a fucntion it will be gone when the function exits. If you declare it global then it will act like a global. That's all you need to know.

>That's all you need to know.
That's a narrow view. Sure, all you need to know to make use of container classes is their interface. However, to use a container class well, it makes sense to understand how it works, if only theoretically. Personally, I wouldn't trust a programmer to write code for me using vectors if he didn't already know how to do the same thing manually with dynamic arrays. Likewise, I wouldn't trust a programmer to write code for me if he didn't know the benefits of vectors and jumped right to the low level solution. ;)

The moral of the story is that when it comes to programming, the more you know, the better off you are.

ok
thanks friends

Quote:

---

Originally Posted by Daved

BTW, in most cases you shouldn't care where the STL container stores its stuff internally, since that is an implementation detail.

---

Not true.
1) TR 1 strongly recommends that vector store its contents in a contiguous block of memory. This is practically guaranteed to become a requirement in the next C++ standard and it's mostly and oversight that this is missing in the current one.
2) The Allocator template parameter of vector is part of the public interface and lets the user decide exactly where that block of memory comes from.

So vector's storage is not an implementation detail at all.

You should know loads of stuff about how libstdc++ works internally. It's good. It's when you try to take shortcuts with the information then you're in trouble.

As a side note, would you not care how std::sort is implemented? Knowledge of the algorithm used is very important.

Quote:

---

Originally Posted by Prelude

>That's all you need to know.
That's a narrow view. Sure, all you need to know to make use of container classes is their interface. However, to use a container class well, it makes sense to understand how it works, if only theoretically. Personally, I wouldn't trust a programmer to write code for me using vectors if he didn't already know how to do the same thing manually with dynamic arrays. Likewise, I wouldn't trust a programmer to write code for me if he didn't know the benefits of vectors and jumped right to the low level solution. ;)

The moral of the story is that when it comes to programming, the more you know, the better off you are.

---

I am looking at things from the point of view of the implementor of he interface for a particular container. They do not require that you know more than this about how it works internally. Make no mistake, it is definately useful to learn and understand the inner workings, and I fully expect non-beginners to delve into this at some stage.

I posted what I did because the original poster thought he needed to know more, when in fact he actually doesn't, so he can stop worrying. That doesn't mean there's anything stopping him from finding out more though.

>> TR 1 strongly recommends that vector store its contents in a contiguous block of memory.
AFAIK, this is already part of the standard. It was added in the techincal corrigendum (which, unlike TR1 is officially part of the standard).

>> So vector's storage is not an implementation detail at all.
Well, yes and no. The fact that the memory is contiguous is part of the interface, IMO, just like the ability to use a custom allocator to affect how data is stored. In most cases, though, you allow the implementation to use its own default storage without worrying about such details.