Re: [avr-gcc-list] Struct problem

[Joerg Wunsch]

As "David Brown" <address@hidden> wrote:

>Basically, standard malloc() / free() implementations can (unless you
>are very careful, or have particular paterns of usage - such as only
>allocating at program startup, and never freeing since your program
>never ends (in which case, why are you using dynamic memory in the
>first place?)) have

In that case, I'd indeed suggest writing your own malloc() anyway. ;-)
It might make sense e. g. to not use the standard malloc() in such a
situation when you want to use stdio with the current implementation.
The librarie's malloc() jumps through through hoops to avoid memory
fragmentation, which of course, costs a lot of code -- that is not
needed at all if you never free it again.

>problems such as memory fragmentation, varying delays when allocating
>memory, failed allocations, memory overheads, etc.  It is frequently better
>to have memory pools for allocation of specifically-size elements, or other
>specific code.

I agree that using various pools might be more better (and thus a good
reason to write your own replacement) for some usage patterns,
although I guess the code will be even more bloated for that (which is
the main reason why I didn't use a pool-based allocator.)  I don't see
how you're going to solve in particular the problem of failed
allocations by just writing your own. ;-)  (Sure, avoiding malloc() is
the only solution to that.)
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/