Re: [boost] Boost: containers and allocators

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-05-22 22:36:47

scleary_at_[hidden] wrote:
> 
> > There is also a good reason for default ctor: to make an instance
> > which is later assigned to.
> 
> This could be useful as optional behavior.  Most containers, though,
> wouldn't allow such an assignment after construction (Does it really make
> sense?  What if objects have already been allocated? ...).

        For an 'instance based allocator', the default
constructor could make an allocator which has ZERO memory
to manage. This means you can't use such an object for 
allocating memory, but it is useful for default
initialising a class member, where the actual instance
is constructed in the body of some constructor.

> > Can Felix GC use/be a standard allocator?
> 
> I think so.

        HOW??
 
> Or just have the shape info be static public data (yuck!) of your Felix
> Allocator:
>   template <typename T>
>   class felix_allocator
>   {
>     public:
>       // sizeof(T) we already know
>       static void (*finaliser)(collector_t *, void *);
>       static int num_offsets;
>       static size_t *offsets;
>   };

        Yes, that would work. (yuk :-)
 

>         // Got a plan for handling allocations of arrays???

        Yes. It is easy to add a 'count' to the shape object.
But this requires a shape object for every array length statically.
So the 'count' can go into the frame_t instead. The collector
then sweeps 'count' objects of the given shape. Another word
of overhead in the frame_t :-(

        The main problem is initialisation: we cannot allow
uninitialised pointers. So you can NOT just make an
array of uninitialised pointers and fill in the ones
you want (as, for example, an efficient implementation
of 'vector<T*>' would do).

        It is possible I will have to 'force initialise'
all pointers to zero the the 'allocate' method.

        This will NOT stop the client 'forgetting'
the 'unused' tail of a vector, which would prevent
these 'unused' objects from being collected. This is what
'vector<T*>' is sure to do. :-(

        Finally: it is NOT obvious how to allocate
an array: we would need to allocate

        struct raw_memory {
                frame_t frame;
                T data[n];
        };

where 'n' is a VARIABLE. I know how big this is, but there
is no way to give the memory supplying allocator a
type to allocate for: we want n copies of T, and ONE frame.

> Also, when I did Pool, I started out trying to make it Standard-compatible
> allocators &tc., but it ended up being way too messy!  In the final design,
> I wrote the basic Pool classes using my own sensible semantics, and wrote a
> Standard Allocator _interface_ to these.  You might want to consider a
> similar approach...  

        That will be necessary I think: the 'standard' allocator
has to be a 'handle' anyhow, since it is 'generalised copy'ied
in containers, and we don't actually want a new collector!

> I guess what I'm saying is: don't mess your code up trying to force it into
> a Standard -- just write it naturally, and then provide a Standard interface
> if possible.

        I've already written it, so the problem remains to make
it (a) use and (b) look like a standard allocator.

-- 
John (Max) Skaller, mailto:skaller_at_[hidden]
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net