Free pool

[Daniel]

Consider a third party container that has a template allocator parameter, defaulting to std::allocator<void>, and rebinds it as needed when allocating fixed size internal data structures.

Now suppose the user of this container decides to apply, for instance, a boost pool_allocator, say as

Container<boost::pool_allocator<void>> val;

and proceeds to add many and diverse items into the container.

At some point, the user is done with the container and wishes to free the memory in the pool, but in the case of the boost pool allocator, that requires the user to know about the internal data structures in the container, along the lines of

boost::singleton_pool<boost::pool_allocator_tag, sizeof(Container::internal_structure1)>::release_memory();

Any suggestions for best practices on the part of the container author for making this convenient for the user?

Thanks,
Daniel

[Öö Tiib]

On Monday, 12 January 2015 17:42:04 UTC+2, Daniel wrote:
> Consider a third party container that has a template allocator parameter, defaulting to
> std::allocator<void>, and rebinds it as needed when allocating fixed size internal data
> structures.
>
> Now suppose the user of this container decides to apply, for instance, a boost pool_allocator,

Juha Nieminen posted that the particular pool_allocator had terrible performance
in his tests couple of years ago.
https://groups.google.com/forum/#!msg/comp.lang.c++/7HWbMzsMCyc/wDd1tIRj_f0J

I simply avoid using it and works great for me. ;)

> say as
>
> Container<boost::pool_allocator<void>> val;
>
> and proceeds to add many and diverse items into the container.

Notice that it was design decision of *user* of the 'Container' to use some custom (or third
party library) allocator with 'Container'.

>
> At some point, the user is done with the container and wishes to free the memory in the pool,
> but in the case of the boost pool allocator, that requires the user to know about the internal
> data structures in the container, along the lines of
>
> boost::singleton_pool<boost::pool_allocator_tag,
> sizeof(Container::internal_structure1)>::release_memory();
>
> Any suggestions for best practices on the part of the container author for making this
> convenient for the user?

If the user does not know some properties of 'Container' but may need those for something
(like 'sizeof(Container::internal_structure1)') then 'Container's author can provide those
with some 'public static constexpr size_t' in interface of 'Container'.

[Daniel]

On Monday, January 12, 2015 at 11:47:37 AM UTC-5, Öö Tiib wrote:
>
> If the user does not know some properties of 'Container' but may need those for
> something
> (like 'sizeof(Container::internal_structure1)') then 'Container's author can
> provide those
> with some 'public static constexpr size_t' in interface of 'Container'.

Thanks, it's a good suggestion, but unfortunately the compilers I need to support
include ones that don't have constexpr.

Daniel

[Öö Tiib]

Oh ... no problem. 'const' works like 'constexpr' for static integral
members. 'constexpr' just makes the intent more clear.

template<class X, size_t N>
class Container
{
X[N] stuff;
public:
static size_t const StuffSize = sizeof(stuff);
};

typedef Container<int, 5> FiveInts;
typedef Container<char, FiveInts::StuffSize> TwentyChars;

[Öö Tiib]

Fix to 'X stuff[N];', strange typo.

[Scott Lurndal]

=?ISO-8859-1?Q?=D6=F6_Tiib?= <oot...@hot.ee> writes:
>On Tuesday, January 13, 2015 at 3:40:50 AM UTC+2, Daniel wrote:

>> On Monday, January 12, 2015 at 11:47:37 AM UTC-5, =D6=F6 Tiib wrote:
>> >=20
>> > If the user does not know some properties of 'Container' but may need t=
>hose for=20
>> > something
>> > (like 'sizeof(Container::internal_structure1)') then 'Container's autho=
>r can=20

>> > provide those
>> > with some 'public static constexpr size_t' in interface of 'Container'.

>>=20

>> Thanks, it's a good suggestion, but unfortunately the compilers I need
>> to support include ones that don't have constexpr.
>
>Oh ... no problem. 'const' works like 'constexpr' for static integral
>members. 'constexpr' just makes the intent more clear.
>
> template<class X, size_t N>
> class Container
> {
> X[N] stuff;
> public:

> static size_t const StuffSize =3D sizeof(stuff);

Technically, this requires a corresponding declaration
in a compilation unit. Most optimizing compilers will
never generate a reference to the declaration, thus you'll
not get a linker error. Try compiling without -O, however
and the results may differ.

[Öö Tiib]

I have not encountered a compiler (or linker) complaining about lack
of definition of such constant unless some code tries to take address
(or reference) to it (that I didn't).