Re: Pointers to global and stack variables

shrey wrote:
> Hi
> I am trying to understand what might be a few major and general
> reasons why programmers might have pointers to global and stack data as
> compared to pointers to heap which are essential to building data
> structures. Based on that I want to find programs with such pointers.
> Some reasons general reasons I can think of are making pointers point
> to a array based on runtime conditions, writing obfuscated but compact
> code , better code generation in DSP processors etc. Can any one
> suggest me any other reasons ?


When writing embedded code you frequently need tight control of your
heap usage, while the amount of memory available for the heap is
given. Often you will have to write you own heap management, because
you need to be sure that garbage collection is done when it cannot
break timing constraints, etc. An easy way of allocating the heap is
to declare it as a global array and let the heap allocation routines
return pointers into that array.


I was once writing a recursive routine, where I need a linked list of
the same length as the depth of the recursion. The easiest way of
allocation memory for that list was to declare a variable in the
recursive routine. Each variable was to hold an element in the list
and was implemented as a record with a field for linking the list.
Then the field used for linking the list pointed from the variable in
one activation record to the variable in an other activation record.
Normally having dynamically allocated data structures stored in the
activation records of routines is a no no, that would make a teacher
of good coding practices hit the roof. However in this case the code
became easier to understand and test, because it was given from the
problem that the list would not be needed after the return of the
routine, and doing it this way I did not have to check for memory
leaks.


Why do you want to study such examples? Both the examples I have given
could have been implemented without using such pointer, but at the price
of an increased overhead or code that is more difficult to maintain. In
the case of embedded computing it is often important that the processor
needed is cheap, e.g., if you intend to sell a million printers, then we
are talking real money if the microprocessor in the printer becomes a
few cents more expensive.


Karsten Nyblad
148f3wg02 at sneakemail dot com

Return to the comp.compilers page.
Search the comp.compilers archives again.