Boost logo

Boost :

From: Gary Powell (powellg_at_[hidden])
Date: 2002-02-18 19:21:46


  Other than container implementations not internally using the
typedefs which the external interface provides, what were the specific
difficulties which arose with using allocators which caused you to
abandon all hope for them in their C++98 form? I think that an
explicit listing of the problems with allocators would stimulate
discussion of potential solutions.
Ok, the two problems I've tried to solve and thus use standard containers
are as follows:

I had a fixed block of memory, it was 32Meg and that's it. So I use a
of resource handles and fixed memory pointers. The resources can be swapped
out at any time. So use a specialized smart pointer (resouce handle)that
to see if the handle has been nulled, and fetch the data again if need be.
can be of any size that fits in what's left of the memory. But while you're
accessing it, you'd better read lock the bits you have, ie. the bit of the
container that I have
access to. Also the container needs to relock the headers it allocated. The
smart pointers can handle this (on a dumb basis, i.e every time a call to ->
is done, but it can be done.) But without a smart reference, I can't tell
the container what to return as a "reference".

template<class DataType, class Alloc>
class TheContainer {
   Allocator::pointer TheData;

typedef TheContainer<myData, myAlloc> myContainerType;

   mySmartPointer<myContainerType> theSpace =
myAllocator(sizeof(myContainerType) );
   myContainerType *ptc new myContainerType(Args) ;

but allocators::allocate pointers"T *", or if possible

   what type is Alloc::reference ?

The second problem involved shared memory and has roughly the same set of
problems plus more. In this case I have fixed size memory pools. (i.e. the
things in the pools are all of the same size.)


Boost list run by bdawes at, gregod at, cpdaniel at, john at