On Tue, Nov 28, 2000 at 09:05:52PM +0100, Branko Cibej wrote: >... > This is a tough question. On the one hand, Greg's right that your > arguments can effectively be used in favour of putting any and all > "useful" utility functions into ARP. On the other hand, one might just > as easily use Greg's arguments to throw pools out of APR and put them in > a separate utility library ...
Currently, all pool implementations use malloc(), but I could see a Windows specific version that uses native Win32 memory mgmt functions to speed things up. There could also be tradeoffs made inside there to get optimum memory allocation speed (e.g. always use malloc, maybe use sbrk on some platforms, use a third-party custom allocator for some platforms cuz their malloc blows chunks, ...) > To me, all of this speaks in favour of creating /another/ library for > such not-sctrictly-portability stuff, and slowly moving the generic bits > out of APR. For all I care this could mean splitting APR into a core and > utility library, but keeping them conceptually together. > > How much sense that makes is another matter. I'm fine with that. Cheers, -g -- Greg Stein, http://www.lyra.org/
