Parameterize the memory allocator for the container library

Parameterize the memory allocator for the container library

[Vivien Kraus]

Dear gnulib developers,

Is it possible to parameterize the memory allocator for the ordered map
library? I see, for instance, that the rbtree implementation uses
gl_rbtree_ordered.h, after defining things like NODE_PAYLOAD_PARAMS. I
think it would be easy to add a couple of function pointers and space
for the closure to parameterize the memory allocator. Has someone
already done something similar? Is there a workaround?

Best regards,

Vivien

Re: Parameterize the memory allocator for the container library

[Bruno Haible]

Hi,

> Is it possible to parameterize the memory allocator for the ordered map
> library?

1) What's the use-case?

2) What's wrong with the approach outlined in
   https://stackoverflow.com/questions/17803456/ ?

Bruno

Re: Parameterize the memory allocator for the container library

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]

Hi,

If I may chime into the discussion, let me remark that local
parameterization of the memory allocator is often useful (while the linker
approach means a global replacement).  For example, part of the
program/library may work with an arena allocator (see, e.g. [1] for a
general discussion) and containers used in this part of the program should
use the arena allocator instead of the global allocator.

The C++ container types have the ability to use custom allocators (see [2]
for some simple benchmarks).

Best,

Marc

--

[1] https://www.rfleury.com/p/untangling-lifetimes-the-arena-allocator
[2]
https://indiegamedev.net/2022/03/27/custom-c20-memory-allocators-for-stl-containers/

Am Sa., 10. Feb. 2024 um 18:28 Uhr schrieb Bruno Haible <bruno@clisp.org>:

> Hi,
>
> > Is it possible to parameterize the memory allocator for the ordered map
> > library?
>
> 1) What's the use-case?
>
> 2) What's wrong with the approach outlined in
>    https://stackoverflow.com/questions/17803456/ ?
>
> Bruno
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2505 bytes --]