 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
bigfaceworm
Guest
|
 Posted: Sat Jan 24, 2004 1:25 pm Post subject: stl allocators - any good resources? |
 |
|
All,
I'm interested in learning more about stl allocators.
Specifically:
1) allocators to memory pools
-> per class
-> per instance (yes, this may be tough to do
and remain standard compliant, but I may
decide to break this for my own containers)
-> per thread
2) writing (container) classes that use allocators
specifically an explaination of how STL implementations
have decided to make the trade-offs. I can look at the
source for STLPort and gcc's stl, but gleaning *why* the
allocator is publically inherited by a class 3 levels down
from the user-visible std::list<> is difficult.
I've googled newsgroups, the web. Looked at CUJ experts journal,
STL Tutorial & Reference Guide, and a couple other places, but
all I've found is just a variant of either a debug/journalling
allocator, or yet another wrapper around malloc/free,new/delete.
Thanks,
BFW
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Pete Becker
Guest
|
| Posted: Sat Jan 24, 2004 9:46 pm Post subject: Re: stl allocators - any good resources? |
|
|
bigfaceworm wrote:
| Quote: |
All,
I'm interested in learning more about stl allocators.
Specifically:
1) allocators to memory pools
-> per class
-> per instance (yes, this may be tough to do
and remain standard compliant, but I may
decide to break this for my own containers)
-> per thread
|
www.dinkumware.com/refxcorex.html. Look at the documentation for the
Dinkum Allocators Library.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Dhruv
Guest
|
| Posted: Sun Jan 25, 2004 1:43 am Post subject: Re: stl allocators - any good resources? |
|
|
On Sat, 24 Jan 2004 08:25:03 -0500, bigfaceworm wrote:
| Quote: | All,
I'm interested in learning more about stl allocators.
Specifically:
1) allocators to memory pools
-> per class
-> per instance (yes, this may be tough to do
and remain standard compliant, but I may
decide to break this for my own containers)
-> per thread
|
Have a look at Hoard. Excellent allocator for Multi-threaded applications.
libstdc++-v3's Pool Allocator (again very good for memory efficiency and
allocation speed for small objects < 128 bytes. However, this allocator
will have a poor cache performance).
| Quote: | 2) writing (container) classes that use allocators
specifically an explaination of how STL implementations
have decided to make the trade-offs. I can look at the
source for STLPort and gcc's stl, but gleaning *why* the
allocator is publically inherited by a class 3 levels down
from the user-visible std::list<> is difficult.
|
To main the compliance between the STL style and SGI style allocators.
Even libstdc++-v3 had these classes floating about until a few days ago, when
the whole mess was cleared up.
Just recently the libstdc++-v3's mt_allocator<> (Multi threaded allocator)
has gotten a major facelift, which has improved it's performance manifold
in client-server kind of applications. You could have a look at that too.
Other allocators could be simple type parameterized allocators that
maintain a free list of only one size, and do not share this memory with
other types. They usually have better cache performance. And then there's
the allocators that perform continuous merging of the free blocks to
ensure a good cache performance. A vairiant of the node allocator would be
a fixed size type parameterized bitmap allocator, which has good cache
efficiency.
Regards,
-Dhruv.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Thomas Beckmann
Guest
|
| Posted: Mon Jan 26, 2004 2:33 pm Post subject: Re: stl allocators - any good resources? |
|
|
Hi,
I implemented a custom allocator class and a base pointer class for a
university homework. The program uses these classes to store stl container
objects in a file on the harddrive, demonstrating the management of
oodb-metadata. The allocator uses memory mapped file I/O and is even capable
of sharing the data among multiple instances of the program:
http://wwwserv2.iai.fzk.de/~thomas/emich/ad/oodb.rar
The archive is 4MB, sorry didn't strip it. The program was developed using
VC6 and works on Win32 only (memory mapped file I/O :-)
One thing I realized while doing the work was that the allocator is part of
the type which has (unfortunate) consequences. Say you want to compare a
std::string using the custom allocator with another std::string using a
standard allocator. Then no proper comparision operator is found! Did I
understand the principle of writing an allocator wrong? -- This way the
current implementation is far less useful as it could be. It's been a while
since I wrote it. Would a public derivation or a copy constructor accepting
std::allocator help?
Regards,
Thomas.
--
PS:
The allocators interface in question starts like this:
[...]
00151 template <typename T>
00152 class persistent_allocator {
00153 public:
00154 typedef T value_type;
00155 typedef size_t size_type; //<! type representing size.
00156 typedef based_ptr
00157
00158 typedef based_ptr<T> pointer; //<! type used as pointer.
00159 typedef based_ptr
00160
00161 typedef T& reference;
00162 typedef const T& const_reference;
00163
00165 pointer address(reference r) const {
00166 return pointer(&r);
00167 }
00169 const_pointer address(const_reference r) const {
00170 return const_pointer(&r);
00171 }
00172
00178 persistent_allocator() throw() {
00179 #ifdef _DEBUG
00180 assert(base);
00181 ++allocators_in_use;
00182 #endif
00183 }
00191 template <typename U>
00192 persistent_allocator(const persistent_allocator<U>& a) throw() {
00193 assert(base);
00194 ++allocators_in_use;
00195 assert(*this == a);
00196 }
00197 #ifdef _DEBUG
00198
00202 ~persistent_allocator() throw() {
00203 --allocators_in_use;
00204 }
00205 #endif
00206
00221 pointer allocate(size_t N, void* hint = 0) {
[...]
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Ben Hutchings
Guest
|
| Posted: Mon Jan 26, 2004 8:25 pm Post subject: Re: stl allocators - any good resources? |
|
|
Thomas Beckmann wrote:
| Quote: | I implemented a custom allocator class and a base pointer class for a
university homework. The program uses these classes to store stl container
objects in a file on the harddrive, demonstrating the management of
oodb-metadata. The allocator uses memory mapped file I/O and is even capable
of sharing the data among multiple instances of the program:
snip
One thing I realized while doing the work was that the allocator is part of
the type which has (unfortunate) consequences. Say you want to compare a
std::string using the custom allocator with another std::string using a
standard allocator. Then no proper comparision operator is found! Did I
understand the principle of writing an allocator wrong? -- This way the
current implementation is far less useful as it could be. It's been a while
since I wrote it. Would a public derivation or a copy constructor accepting
std::allocator help?
|
Public derivation wouldn't help, but a converting constructor (not a copy
constructor) would. However, there's no need to do conversion when you
can compare directly, like this:
template<class charT, class traits, class Allocator1, class Allocator2>
bool operator==(const std::basic_string<charT, traits, Allocator1> & lhs,
const std::basic_string<charT, traits, Allocator2> & rhs)
{
return lhs.length() == rhs.length()
&& traits::compare(lhs.data(), rhs.data(), lhs.length()) == 0;
}
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Allan W
Guest
|
| Posted: Wed Jan 28, 2004 1:38 pm Post subject: Re: stl allocators - any good resources? |
|
|
| Quote: | Thomas Beckmann wrote:
I implemented a custom allocator class and a base pointer class for a
One thing I realized while doing the work was that the allocator is part of
the type which has (unfortunate) consequences. Say you want to compare a
std::string using the custom allocator with another std::string using a
standard allocator. Then no proper comparision operator is found! Did I
understand the principle of writing an allocator wrong? -- This way the
current implementation is far less useful as it could be. It's been a while
since I wrote it. Would a public derivation or a copy constructor accepting
std::allocator help?
|
Ben Hutchings <do-not-spam-benh (AT) bwsint (DOT) com> wrote
| Quote: | Public derivation wouldn't help, but a converting constructor (not a copy
constructor) would. However, there's no need to do conversion when you
can compare directly, like this:
template<class charT, class traits, class Allocator1, class Allocator2
bool operator==(const std::basic_string
const std::basic_string<charT, traits, Allocator2> & rhs)
{
return lhs.length() == rhs.length()
&& traits::compare(lhs.data(), rhs.data(), lhs.length()) == 0;
}
|
Assuming that your vendor's library doesn't already do this, wouldn't
the user have to do this for every single data type provided, i.e.
vector, list, map, ...?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Ben Hutchings
Guest
|
| Posted: Wed Jan 28, 2004 8:41 pm Post subject: Re: stl allocators - any good resources? |
|
|
Allan W wrote:
| Quote: | Thomas Beckmann wrote:
I implemented a custom allocator class and a base pointer class for a
One thing I realized while doing the work was that the allocator is part of
the type which has (unfortunate) consequences. Say you want to compare a
std::string using the custom allocator with another std::string using a
standard allocator. Then no proper comparision operator is found! Did I
understand the principle of writing an allocator wrong? -- This way the
current implementation is far less useful as it could be. It's been a while
since I wrote it. Would a public derivation or a copy constructor accepting
std::allocator help?
Ben Hutchings <do-not-spam-benh (AT) bwsint (DOT) com> wrote
Public derivation wouldn't help, but a converting constructor (not a copy
constructor) would.
|
Actually I misread the question - I thought Thomas Beckmann meant a
converting constructor for the container, not the allocator. I don't
see that a converting constructor for the allocator would help at
all.
| Quote: | However, there's no need to do conversion when you can compare directly,
like this:
template<class charT, class traits, class Allocator1, class Allocator2
bool operator==(const std::basic_string
const std::basic_string<charT, traits, Allocator2> & rhs)
{
return lhs.length() == rhs.length()
&& traits::compare(lhs.data(), rhs.data(), lhs.length()) == 0;
}
Assuming that your vendor's library doesn't already do this, wouldn't
the user have to do this for every single data type provided, i.e.
vector, list, map, ...?
|
Yes, unfortunately so - and additionally these functions wouldn't be
visible to functions in namespace std. Still, I think the alternative
is to convert one of the two containers with different allocators
before comparing them, and that's probably unacceptable.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
