apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@xbc.nu>
Subject Re: RogueWave Standard C++ Library proposal in Incubator
Date Thu, 19 May 2005 06:16:14 GMT
Marc M. Adkins wrote:

>
>
> 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.

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


Mime
View raw message