hurry wrote:
In order to avoid declaring static variables in a function I was asked
to write a scratch memory.
Reserve a block of memory outside the function and assigning pointers
to the memory locations as per convenience and access them.
I was told this would save some memory. I dont understand the logic
behind this, as i`ve declared variables as global (assuming i`ve
declared the block in main() ) this would always b a residual data for
access at any point of the prog. against static var. which wud b
available for access only whn it enters the function.
If anyone has ever written a scratch memory pls confirm if my
understanding is right and its use too.
All of a program's static objects (whether inside
or outside of functions) exist and occupy their memory
for the entire duration of the program. If the program
doesn't actually need all of them simultaneously, that
might amount to a waste of memory. For example, imagine
a program that proceeds in "phases:" it initializes, it
does the first, second, ... parts of its calculation,
then it writes its results, cleans up, and terminates.
If there are functions that are used only in Phase N and
not in any earlier or later phases, the memory their
static variables occupy is wasted except while Phase N is
actually running.
However, using dynamically-allocated memory has plenty
of pitfalls and offers many chances for you to gain practice
with the debugger ... Before embarking on some kind of
wholesale replacement of static with dynamic memory, you
should assess just how much waste there actually is, whether
that's important in the Grand Scheme of Things. Changing
your car's motor oil regularly can help your gas mileage,
but changing it every day is a false economy.
also any link to understand on how memory is handled during a
c-program`s (on windows) execution would b of hlp.
Each data object in C has a "storage duration," or loosely
speaking a "lifetime." There are three such:
- Static storage duration: The data object exists and
occupies memory for the entire execution of the program,
as described above. Static storage should, IMHO, be
used sparingly, especially static storage with external
linkage ("global variables").
- Automatic storage duration: The data object "belongs"
to a block of executable code (a function, or a sub-
block within a function). The object's lifetime is
tied to the execution of the block: while the block
is active, the object exists and occupies memory, but
when execution leaves the block the object disappears
and its memory becomes available for other objects to
occupy. If a block is entered recursively, a whole
new set of block-local objects is created, occupying
memory that is distinct from that of the outer blocks.
- Dynamic storage duration: You control the lifetime of
the object explicitly, granting it memory and rescinding
the grant whenever you choose. You use malloc() or
calloc() or realloc() to allocate the memory, and free()
or realloc() to release it. This is the most flexible
method, and also the most error-prone.
Specific implementations of C may take liberties with the
schemes outlined above, so long as a conforming program cannot
tell that they've cheated. For example, an implementation
might decide to allocate memory for an auto variable before
its block is entered, and retain the memory for some time
after execution leaves the block:
void func(void) {
{
/* subordinate block 1 */
int inner1 = 42;
...
}
{
/* subordinate block 2 */
double inner2 = 42.0;
...
}
}
Some implementations might allocate memory for both inner1
and inner2 as soon a func() is called, without waiting for
their subordinate blocks to be entered. Such implementations
are also likely to keep that memory around until func() returns,
even though (in principle) inner1 and inner2 cease to exist
when their blocks end. Such shenanigans are permitted in the
name of efficiency, but are not to be relied upon -- for
example, this would be an error:
void func(void) {
int *ptr;
{
/* subordinate block */
int inner = 42;
ptr = &inner;
...
}
printf ("%d\n", *ptr); /* WRONG! */
}
.... because when the subordinate block finishes, the memory
allocated to inner may (in principle, "does") disappear, so
ptr finds itself pointing at something that no longer exists.
To find out whether the compiler you happen to be using
does this sort of thing, and under what circumstances, consult
its documentation. But the wiser course may be to remain
intentionally ignorant, lest you start confusing what your
current compiler happens to do with what the C languages
promises it will do. Upgrade to a newer version of the compiler,
and all the non-promised behaviors are subject to change.
--
Eric Sosman
es*****@acm-dot-org.invalid
