> It has a QVGA GLCD with multiple pages of user interface. Memory to support
> the graphical objects and some associated strings and lists on a page is
> only required while that page is displayed. I need enough heap to support
> the most complex page. I would need enough static allocation to support all
> pages.

Why? You could allocate a structure for the needs of each page, and 
those structures could overlap (variant structure).

> I have no other requirement for dynamic allocation in the system so I know
> the heap will empty on every page change. I can check this happens and use
> a dumb heap management scheme which can't fragment and is easy to monitor. 

I would say that you don't 'fully' use a heap. In a language that 
supports this (variable-size arrays, etc) you could use variable-size 
on-stack allocation.

> If I flip through all the GUI pages I know I have seen the peak heap usage.
> It is an example of the kind of system where using a heap over static
> allocation is a complete no brainer. 

Except that (to pass certain qualifications/quality systems/to convince 
me if I were the customer) you would have to prove that what you state 
is indeed what your code does. Which might be easier if you would not 
use the full-blown malloc/free but rather (for instance) an Ada-style 
'allocation from a fixed pool that is deallocated at once'.

> Sure I can envisage systems where the opposite is true. In between there
> are plenty of systems where the greater efficiency of a heap allows for
> enough contingency to mitigate uncertainty in worst case heap requirements.

I still hold that in situations where you can prove that malloc/free 
'gives no troubles' other schemes that are guaranteed to give no 
troubles are more appropriate. It is a pity that such schemes are not in 
the standard toolbox of most (some?) C programmers.

-- 

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu

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