[vsipl++] [patch] Pool allocation

[Stefan Seefeld]

Jules,

sorry for having dropped the ball here. The patch looks good. I only 
have the usual nit-picks, but nothing blocking.

A general question concerning the expected usage: By replacing the 
template parameter by a function parameter you make the choice of a pool 
a runtime-only thing. Who do you expect will use pools explicitly, and 
how ? Is this runtime-binding really going to be used by end-users, or 
is it merely a convenience for us during R&D ?
(I could think of ways to keep the allocator a compile-time parameter, 
but allow us to configure in a special allocator that calls into a 
runtime-polymorphic pool type such as the one you implement here...)


Jules Bergmann wrote:

> Index: src/vsip/core/pool.hpp
> ===================================================================
> --- src/vsip/core/pool.hpp	(revision 0)
> +++ src/vsip/core/pool.hpp	(revision 0)
> @@ -0,0 +1,81 @@
> +/* Copyright (c) 2007 by CodeSourcery, LLC.  All rights reserved. */

This should be Inc., not LLC., right ?

> +
> +/** @file    vsip/core/pool.hpp
> +    @author  Jules Bergmann
> +    @date    2007-04-11

Is this patch really this old ? :-)

> +    @brief   VSIPL++ Library: Memory allocation pool
> +*/

I would prefer to name the pool actually Memory_pool, to make it clear 
that we are talking about memory management here, not threading (say).

> +template <typename T>
> +inline T*
> +pool_alloc(
> +  Pool*       pool,
> +  length_type size)
> +{
> +  return (T*)(pool->allocate(size * sizeof(T)));
> +}

I understand the need for 'pool_alloc' being a separate function from 
the virtual Pool::allocate, but I'd still prefer this to become a member 
function. What about

class Memory_pool
{
public:
   virtual void *allocate(length_type);
   template <typename T>
   T * allocate(length_type);
};

?

Thanks,
		Stefan


-- 
Stefan Seefeld
CodeSourcery
stefan at codesourcery.com
(650) 331-3385 x718