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

properties of the default STL allocator

P: n/a
Hi,

I'm looking for some info on the default STL allocator, std::alloc. In
particular, I'm wondering if it is optimized to handle many allocations
of small objects. I'm thinking along the lines of a pool-based
approach, for example.

Any references would also be appreciated.

Thanks,
Mark
Jul 23 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Mark P wrote:
I'm looking for some info on the default STL allocator, std::alloc.
You mean std::allocator, don't you?
In
particular, I'm wondering if it is optimized to handle many allocations
of small objects. I'm thinking along the lines of a pool-based
approach, for example.


I don't think so. The Standard defines it as using '::operator new'
(see 20.4.1.1). There is a special "hint" argument, but beyond that
the hint "may be used to help improve performance", the use of 'hint'
is unspecified.

I recommend you to look in the source for your library to see if it does
utilise any particular scheme/approach.

V
Jul 23 '05 #2

P: n/a
Victor Bazarov wrote:
Mark P wrote:
I'm looking for some info on the default STL allocator, std::alloc.

You mean std::allocator, don't you?


Hmm, maybe I don't mean default STL allocator. My system appears to use
the SGI STL implementation and according to the SGI docs, their default
allocator is std::alloc. It hadn't occurred to me that this might be
distinct from the default STL allocator.
> In

particular, I'm wondering if it is optimized to handle many
allocations of small objects. I'm thinking along the lines of a
pool-based approach, for example.

I don't think so. The Standard defines it as using '::operator new'
(see 20.4.1.1). There is a special "hint" argument, but beyond that
the hint "may be used to help improve performance", the use of 'hint'
is unspecified.

I recommend you to look in the source for your library to see if it does
utilise any particular scheme/approach.

V


I looked into stl_alloc.h and there are comments such as, "We allocate
memory in large chunks in order to avoid fragmenting the malloc heap too
much." At the same time, I find these headers difficult to comprehend
so I'm not sure if this does what I think it does.

Mark
Jul 23 '05 #3

P: n/a
Mark P wrote:
Victor Bazarov wrote:
Mark P wrote:
I'm looking for some info on the default STL allocator, std::alloc.
You mean std::allocator, don't you?

Hmm, maybe I don't mean default STL allocator. My system appears to use
the SGI STL implementation and according to the SGI docs, their default
allocator is std::alloc. It hadn't occurred to me that this might be
distinct from the default STL allocator.


Well... My fault. We should agree on using the same terminology, then.
If you mean "the default *Standard* allocator", it's 'std::allocator'. If
you don't meant the *Standard* allocator, but instead mean some old, and
proprietary implementation of "Standard Template Library" (which, when was
incorporated into the Standard Library, lost the 'STL' designator), then I
can't help you, try talking to the proprietors of that implementation.

The standard header <memory> contains several things, and 'std::allocator'
template is one of them. Its implementation is not really governed by the
Standard, but its interface and some basic stuff is. The description of
them is in subclause 20.4 of the 1998 Standard (most likely the same in
the newest edition as well).
[...]
I looked into stl_alloc.h and there are comments such as, "We allocate
memory in large chunks in order to avoid fragmenting the malloc heap too
much." At the same time, I find these headers difficult to comprehend
so I'm not sure if this does what I think it does.


I wish I could help you with that...

V
Jul 23 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.