It should certainly be possible to use the APR memory pool system. However, it pretty much needs to be used in a global sense (i.e., one pool for all bstrings), since Bstrlib does not support any kind of "per context" bstring allocation.
To use the APR in a more serious way, you would want to modify Bstrlib extensively to add an extra opaque context parameter on all "create" functions, but you would also want to store the context parameter in the bstring header and pass it as an extra parameter to the bstr__[alloc/realloc/free]() macros. Then you would override the bstr__[alloc/realloc/free]() macros which implementations that map to APR. There isn't a simple way to do that in the current Bstrlib that wouldn't be disruptive to the API even with clever macro tricks (think about the bformat function.)
--
Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi! Would be possible to use APR's memory pool as memory allocation engine in bstring? Do you have any plans to port it?
Thanks and congrats to this great project!
Regards,
E.J.
It should certainly be possible to use the APR memory pool system. However, it pretty much needs to be used in a global sense (i.e., one pool for all bstrings), since Bstrlib does not support any kind of "per context" bstring allocation.
To use the APR in a more serious way, you would want to modify Bstrlib extensively to add an extra opaque context parameter on all "create" functions, but you would also want to store the context parameter in the bstring header and pass it as an extra parameter to the bstr__[alloc/realloc/free]() macros. Then you would override the bstr__[alloc/realloc/free]() macros which implementations that map to APR. There isn't a simple way to do that in the current Bstrlib that wouldn't be disruptive to the API even with clever macro tricks (think about the bformat function.)
--
Paul