Tamas Rudnai wrote:
>> I described what we do, in another post, but here it is again.There are
>> objects (structs, linked lists) that get created once per program 
>> lifetime.
>> There are other objects that get created and destroyed on an ongoing 
>> basis
>> (my example was messages).
>>
>
> Someone mentioned earlier the memory pool as a solution. Once I made an
> allocation method like that. Actually I needed three different sizes of
> blocks and it was kind of hard to predict how much I need of this or that
> sizes. Finally it ended up in a sub-allocation way, and worked great, so
> that first you needed a bigger block from the big bucket from the big 
> pool,
> then you could put either of the two smaller pool in it. Still it is not a
> very easy thing to implement especially if you want a realloc to be
> implemented, but I agree it was working much better than malloc/free and
> also virtually there was no fragmentation problem.
>
> This was not on an embedded and microcontroller environment though. It was
> for a software that was running 24/7 therefore fragmentation and leaks 
> were
> the no.1 enemy.

Did I ever mention that my work computer sometimes goes without rebooting 
for weeks? And I'm the kind of guy who likes to keep Photoshop, WinAmp, 
email client, IM app, multiple instances of MPLAB, EAGLE, PDF documents, web 
pages, and a dozen helper apps all open at the same time to do whatever it 
is I need to accomplish.

Dynamic memory allocation is not evil. And the current trend in software and 
hardware prices suggests that it is important to write software in the 
easiest and most straightforward way possible.

Vitaliy 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist