apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc M. Adkins" <Softw...@Doorways.org>
Subject Re: RogueWave Standard C++ Library proposal in Incubator
Date Tue, 17 May 2005 21:32:01 GMT


Branko ─îibej wrote:
> Wesley W. Garland wrote:
>> instead of malloc and they'd be have a product I'd use
>> in a heartbeat.
>>  
>>
> Not 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.

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

Mime
View raw message