Boost logo

Boost :

Subject: Re: [boost] [pool] Objects of varying sizes
From: Nikolay Mladenov (nikolay.mladenov_at_[hidden])
Date: 2012-06-26 12:42:15


1) size_type is just a type, and it should be able to hold the eventual
size of the biggest requested object

   if size_type == boost::uint32_t you can request to allocate sizes of up
to 2^32 - 1

   size_type == size_t is probably ok for general use.

2) the first parameter in the pools constructor is the *chunk size*, which
is the smallest amount of memory you can allocate
and defines the granularity of your pool.

3) ordered_malloc(n) allows you to allocate a continuous array of n chunks.
I think you have to free those with ordered_free.

HTH

On Tue, Jun 26, 2012 at 12:19 PM, Robert Dailey <rcdailey.lists_at_[hidden]>wrote:

> On Mon, Jun 25, 2012 at 6:48 PM, Klaim - Joël Lamotte <mjklaim_at_[hidden]
> >wrote:
>
> > Hi,
> >
> > don't look at the object_pool, look at pool. It provide only allocation
> and
> > destruction methods, given a size at runtime.
> > That way you can wrap it with a template function that give the size of
> the
> > object you want to create to the pool for it to allocate memory for you.
>
>
> Thanks for the response. I am reviewing the boost.pool reference here:
> http://www.boost.org/doc/libs/1_49_0/libs/pool/doc/html/boost/pool.html
>
> Based on that, I do not see a way to allocate blocks of varying sizes. The
> documentation makes it sound like I have to set size_type to the largest
> object that will be allocated, which I have no reasonable way of knowing (I
> have hundreds of objects in my inheritance hierarchy, each with varying
> size, and no way to calculate the largest in a maintainable way).
>
> The malloc() method does not take any parameters.
>
> Am I misunderstanding you? Could you please point me in the right
> direction? Thanks again for your help.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk