By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,851 Members | 2,097 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,851 IT Pros & Developers. It's quick & easy.

do STL containers buffer nodes to pools?

P: n/a

If you have STL containers (like list, vector,...) in
functions as automatic variables, do the nodes that
are put on the containers get buffered so they can be reused
by later container operations?

For example, if I have 10 member methods, and lots of them have
a list <Foo*> when that list is cleared or goes out
of scope, the nodes are deleted (don't worry about deleting the
Foo* themselves, they are just extra pointers to classes in a
DB, in this program the list being cleared or out of scope doesn't
mean the pointers are lost and memory leaked)

But are they really deleted or does STL buffer them in a pool
somewhere so that the next method when it does

list<Foo*> mylist;
mylist.push_back(fooptr);

could just grab a node from a pool and put the fooptr in it
without newing a node? I've read that to do this buffering for
STL, you'd have to get a special allocator to do that.. implying
the default allocators you get with a compiler like Gcc don't
do buffering?
Mark

Jul 23 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Mark wrote:

If you have STL containers (like list, vector,...) in
functions as automatic variables, do the nodes that
are put on the containers get buffered so they can be reused
by later container operations?

For example, if I have 10 member methods, and lots of them have
a list <Foo*> when that list is cleared or goes out
of scope, the nodes are deleted (don't worry about deleting the
Foo* themselves, they are just extra pointers to classes in a
DB, in this program the list being cleared or out of scope doesn't
mean the pointers are lost and memory leaked)

But are they really deleted or does STL buffer them in a pool somewhere
so that the next method when it does

list<Foo*> mylist;
mylist.push_back(fooptr);

could just grab a node from a pool and put the fooptr in it
without newing a node? I've read that to do this buffering for
STL, you'd have to get a special allocator to do that.. implying
the default allocators you get with a compiler like Gcc don't
do buffering?
Mark


I found a SGI url that seems to suggest that some kind of buffering
can go on, referring to the section called:

"Why does Bounds CheckerTM say that I have memory leaks?"
http://www.sgi.com/tech/stl/FAQ.html

but another thing I'm wondering is over what scope does
this work over? If I have a file1.cc and file2.cc defining
different class methods, will STL share the memory everywhere
for list operations in the program or only among containers that are
in each particular class?
Mark

Jul 23 '05 #2

P: n/a
On Thu, 14 Apr 2005 11:22:37 -0400 in comp.lang.c++, Mark
<no**@xxxyy.com> wrote,
If you have STL containers (like list, vector,...) in
functions as automatic variables, do the nodes that
are put on the containers get buffered so they can be reused
by later container operations?


When the container is destroyed, all of the memory it is using is
returned to the general free memory pool. That memory can then be
reused for later container operations or any other kind of dynamic
memory allocation.

Jul 23 '05 #3

P: n/a
David Harmon wrote:
On Thu, 14 Apr 2005 11:22:37 -0400 in comp.lang.c++, Mark
<no**@xxxyy.com> wrote,
If you have STL containers (like list, vector,...) in
functions as automatic variables, do the nodes that
are put on the containers get buffered so they can be reused
by later container operations?

When the container is destroyed, all of the memory it is using is
returned to the general free memory pool. That memory can then be
reused for later container operations or any other kind of dynamic
memory allocation.


I guess you mean the free pool of the operating system in general,
ie. delete is being called. I found some information after my post
that suggests it doesn't do that (REF: stl_alloc.h in gcc's headers
for STL) but rather buffers the objects. If you request something
bigger than 128 bytes, it malloc/news it, but if < 128 bytes it gets
it from a pool. I'm just trying to confirm that or figure out the details

Ref: last paragraph at this SGI site:
http://www.sgi.com/tech/stl/FAQ.html

Mark

Jul 23 '05 #4

P: n/a
On Thu, 14 Apr 2005 14:12:59 -0400 in comp.lang.c++, Mark
<no**@xxxyy.com> wrote,

I guess you mean the free pool of the operating system in general,
ie. delete is being called.
Yes, delete is called. Memory is returned to the pool managed by the
runtime library. Most implementations will not ordinarily return any
memory to the operating system until the program ends.
I found some information after my post
that suggests it doesn't do that (REF: stl_alloc.h in gcc's headers
for STL) but rather buffers the objects.


The objects have been destroyed. I have no idea really what you mean
by "buffer" them.
Jul 23 '05 #5

P: n/a
Mark wrote:

If you have STL containers (like list, vector,...) in
functions as automatic variables, do the nodes that
are put on the containers get buffered so they can be reused
by later container operations?


You don't know, simple as that. Memory handling of std::allocator is at the
discretion of the implementation, and it can do whatever it wants. Someone
posted a snippet from the GCC docs elsewhere that indicates it buffers, but
that means nothing.

If you want to make sure it's buffering, write your own allocator. Or find
one on the web, I'm sure there are implementations out there.

--
Sebastian Redl
Jul 23 '05 #6

P: n/a
David Harmon wrote:
On Thu, 14 Apr 2005 14:12:59 -0400 in comp.lang.c++, Mark
<no**@xxxyy.com> wrote,
I guess you mean the free pool of the operating system in general,
ie. delete is being called.

Yes, delete is called. Memory is returned to the pool managed by the
runtime library. Most implementations will not ordinarily return any
memory to the operating system until the program ends.

I found some information after my post
that suggests it doesn't do that (REF: stl_alloc.h in gcc's headers
for STL) but rather buffers the objects.

The objects have been destroyed. I have no idea really what you mean
by "buffer" them.


By buffer I mean exactly that the memory is returned to the pool
managed by the library and not to the OS via the global delete.
Mark

Jul 23 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.