Marc M. Adkins wrote:
Branko Äibej wrote:
Wesley W. Garland wrote:
instead of malloc and they'd be have a product I'd useNot that I can see how pools would be better for C++ object allocation... it sort of defeats the "resource allocation is construction" idea if your "freed" objects hang around in memory until you happen to clear a pool.
in a heartbeat.
The idea is that instead of frittering away many little bits of time allocating and reclaiming small bits of memory you can grab a big piece (or something that acts like a big piece) and just chip off little bits of it as you need them. If you are coding some sort of periodic function where all of the data bits go away at the same time this works really well. Start function, grab pool, use memory, release pool at end of transaction. No fuss no muss.
Sure. The problem is that, to preserve correct C++ semantics, you still have to call object destructors at the right time. That means you either have to add an apr_pool_free (in which case the pool itself becomes prone to fragmentation), or you leave the objects' storage allocated after descruction. Which could be acceptable, given the usage pattern you describe.
In either case, you have to make sure that the pool's lifetime is always longer than the lifetime of the objects you allocate in it. The C++ compiler won't help you there, so it's highly error-prone when compared to what you can do with smart pointers. (Sure, the C way of memory management is highly error-prone too, but pools actually help you somewhat because you can register "destructors" in pool cleanups. The object vs. pool lifetime issue is the samein C and C++, though.)
-- Brane
