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.
The pools are usually easier to manage and less prone to memory fragmentation over the long haul then smaller bits of memory. On the other hand, apparently there is an 8K per-pool overhead to worry about. So they should be non-trivial blocks of memory.
In short, pools are great for transaction-oriented code. Like a web server. But then I'm obviously preaching to the choir at this point.
Now what _I_ always end up wanting is some really good overlay for shared memory. Something that would allow me to allocate objects of interesting complexity in shared memory areas without having to chew through all the pointer conversions (segment offsets and so forth, usually very ugly). So I can build a shared queue or blackboard or scheduling object and have it just work.
After that, distributed cross-platform virtual shared memory objects...(bwaaa-ha-ha-ha)...
mma
