stack vs. heap
jack...@hotmail.com
What is the difference between the stack and heap?. How do we place
the different variables in these locations?. Compiler does it for us
or we have to specify it?. Like, taking bunch of stuff to an house.
Do we specify the location on their labels or someone who is doing
it knows where to put them?. I know this is a silly way to put it
but I am trying my best.
Sent via Deja.com http://www.deja.com/
Before you buy.
Ben Pfaff
> What is the difference between the stack and heap?.
A stack is a last-in-first-out data structure.
A heap is a last-in-smallest-out data structure.
> How do we place the different variables in these
> locations?. Compiler does it for us or we have to specify
> it?.
You generally have to construct either data structure explicitly.
> Like, taking bunch of stuff to an house. Do we specify the
> location on their labels or someone who is doing it knows where
> to put them?. I know this is a silly way to put it but I am
> trying my best.
Well, you could build your own or use someone else's, but you
don't get anything "for free" from the C language.
If you're not talking about ADTs but indeed you're talking about
a "stack" as a place for storing automatic variables and a "heap"
as a place for storing dynamically allocated objects, then these
are system specific, and they're not guaranteed to be stored in
any particular manner or even to exist in a conventional sense.
The compiler manages the former on its own and the latter as you
instruct it with malloc() and friends.
Mark A. Odell
>Hi,
>
>What is the difference between the stack and heap?. How do we place
>the different variables in these locations?. Compiler does it for us
>or we have to specify it?. Like, taking bunch of stuff to an house.
>Do we specify the location on their labels or someone who is doing
>it knows where to put them?. I know this is a silly way to put it
>but I am trying my best.
Automatic things get allocated on the stack as in:
char arr[100]; <--- NOT on the stack, I don't know where it is.
void foo(void)
{
int idx; <--- On the stack.
char *ptr; <--- On the stack.
static int var; <--- NOT on the stack.
ptr = malloc(1024);
if (ptr)
{
/*
At this point, ptr, is still on the stack
but it points to a block of 1024 bytes on
the heap. Don't forget to free heap allocations
when you're done or you'll leak memory. The
stack is automatic in this respect, just return.
*/
free(ptr);
}
}
--
- Mark
Replace email username with my first name if you need to email me.
Above all, try to be more like me - it makes me feel validated.
Martin Ambuhl
jack...@hotmail.com wrote:
>
> Hi,
>
> What is the difference between the stack and heap?. How do we place
> the different variables in these locations?. Compiler does it for us
> or we have to specify it?. Like, taking bunch of stuff to an house.
> Do we specify the location on their labels or someone who is doing
> it knows where to put them?. I know this is a silly way to put it
> but I am trying my best.
Strictly speaking, you ought not be asking this question here. The reason is
that the "stack" and "heap" refer to implementation-specific design details.
There is nothing in the language that requires anything known as a "stack" or
"heap". A short explanation may help, however.
When you call a function, the values passed as arguments must be stored
somewhere. Similarly, any auto variables in the function must be created
somewhere. It is usually helpful to have a part of memory which is accessed
reasonably quickly to be set aside for this. Since you we want this to be
resident as often as possible -- swapping defeats the idea of quick access --
this is usually done in an area of memory small relative to the address
space. A natural approach to handling such a space is through a logical
structure called a stack. This leads to the physical space also being
frequently known as "the" stack. It is handled by your implementation
invisibly to you (until you overflow it).
Much of your machine's address space will not have been allocated statically
or assigned to the stack, should you have one. This is what is known in C as
the "free store". "Heap" is an ALGOL-derived near synonym for "free store".
It is available for dynamic allocation, most often through the
malloc/calloc/realloc family. For objects for which the size is not known at
compile time, such allocation is necessary. It is also useful for large
objects (i.e. arrays) which could have been created as auto variables. This
is almost the only time when it is useful to you to make any "stack"/"heap"
distinctions. Because the stack will usually be of a fixed, relatively small,
size, you need to preserve it for arguments and for the minmal set of auto
variables that will enable you to find objects. Auto allocation of large
objects -- including passing structs to functions -- can easily exhaust this
"stack". This is why you want to 1) pass pointers to structs as arguments and
2) dynamically allocate large objects as much as possible.
For the most part, you should not otherwise be concerned with such things.
Remember that another compiler -- or even the next version of the one you have
-- may use another approach to managing memory. If you stick to sane choices
in the use of static objects, auto objects, and dynamically allocated objects,
you will rarely need to be concerned with such implementation details.
--
Martin Ambuhl mam...@earthlink.net
What one knows is, in youth, of little moment; they know enough who
know how to learn. - Henry Adams
A thick skin is a gift from God. - Konrad Adenauer
Clark
> What is the difference between the stack and heap?. How do we place
> the different variables in these locations?. Compiler does it for us
> or we have to specify it?.
The stack is a LIFO (last-in, first-out) data structure, used for things
like passing parameters to function calls and returning the value of a
function call (dependent, of course, on the calling convention either
implicitly or explicitly specified), storing the return address of the
calling function during a function call such that the called function can
return to the proper place, etc. The stack is created by the compiler, and
maintained by the C runtime environment. I don't recall any functions in C
that let you directly manipulate the stack (although I could be wrong, I
have been away from C for awhile). The stack usually starts at the highest
memory address and grows downward.
The heap, on the other hand, is the remaining memory that resides between
your program and the C runtime environment (located in low memory), and the
stack. The heap is the memory used for dynamic allocations such as
alloc( ), calloc( ), etc. The heap is strictly manipulated by you.
good luck,
clark, formerly a.k.a. studpup
Richard Heathfield
>
> > What is the difference between the stack and heap?. How do we place
> > the different variables in these locations?. Compiler does it for us
> > or we have to specify it?.
>
> The stack is a LIFO (last-in, first-out) data structure, used for things
> like passing parameters to function calls and returning the value of a
> function call (dependent, of course, on the calling convention either
> implicitly or explicitly specified), storing the return address of the
> calling function during a function call such that the called function can
> return to the proper place, etc. The stack is created by the compiler, and
> maintained by the C runtime environment.
This is not necessarily true. The Standard doesn't even mention the word
"stack" (or "heap" for that matter). Your answer is based entirely on
local knowledge of your implementation.
> I don't recall any functions in C
> that let you directly manipulate the stack (although I could be wrong, I
> have been away from C for awhile).
You're right. Since C doesn't require a stack, it doesn't bother to
supply functions to manipulate one.
> The stack usually starts at the highest
> memory address and grows downward.
On your system. How about an IBM mainframe? What about a Palm III? Atari
ST? A Vax?
>
> The heap, on the other hand, is the remaining memory that resides between
> your program and the C runtime environment (located in low memory), and the
> stack.
Again, the Standard neither requires nor even mentions this.
> The heap is the memory used for dynamic allocations such as
> alloc( ), calloc( ), etc.
C doesn't have an alloc() function.
> The heap is strictly manipulated by you.
...or your implementation. But not by C, and not portably.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
51 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (46
to go)
Clark
Richard Heathfield <bin...@eton.powernet.co.uk> wrote in message
news:395CE795...@eton.powernet.co.uk...
> Clark wrote:
> This is not necessarily true. The Standard doesn't even mention the word
> "stack".
Mentioned, or not, where do the return addresses go when a series of
functions is called. They don't go in registers do they? They go into a
little data structure in memory which is affectionately known as the stack.
> > The stack usually starts at the highest
> > memory address and grows downward.
>
> On your system. How about an IBM mainframe? What about a Palm III? Atari
> ST? A Vax?
Granted!
> > The heap, on the other hand, is the remaining memory that resides
between
> > your program and the C runtime environment (located in low memory), and
the
> > stack.
>
> Again, the Standard neither requires nor even mentions this.
Once again, whether the "Standard" mentions it or not there is, in most
cases at least, free memory. Where else could dynamic memory allocations
come from, the hard drive? This free memory is affectionately known as the
heap. Perhaps the Standard does mention it but is is kinda funny how many
textbooks and other electronic media do.
>
> C doesn't have an alloc() function.
>
Oops, that was a typo -- was supposed to be malloc( )
Lew Pitcher
<cl...@contemporaryresearch.com> wrote:
>
>Richard Heathfield <bin...@eton.powernet.co.uk> wrote in message
>news:395CE795...@eton.powernet.co.uk...
>> Clark wrote:
>
>> This is not necessarily true. The Standard doesn't even mention the word
>> "stack".
>
>Mentioned, or not, where do the return addresses go when a series of
>functions is called.
They go where ever the compiler writer decided to put them. On OS/390,
they go in a block allocated off of the heap, and pointed to by
register 1. The return address goes in register 15.
> They don't go in registers do they?
Sometimes they do. Some compilers use registers exclusively
(especially when they are cheap and plentiful, like some RISC
architectures).
> They go into a
>little data structure in memory which is affectionately known as the stack.
Not always. I know of implementations that use a 'virtual stack'
consisting of a linked list of 'heap' memory managed by the C runtime,
so as to seperate C parameters from the _processor's_ stack. This has
the benefit of avoiding activation-record corruption by buffer
overflow.
>
>> > The stack usually starts at the highest
Not always. Some stacks are implemented in low memory. It depends on
the machine architecure and operating system environment.
>> > memory address and grows downward.
>>
>> On your system. How about an IBM mainframe? What about a Palm III? Atari
>> ST? A Vax?
>
>Granted!
>
>> > The heap, on the other hand, is the remaining memory that resides
>between
>> > your program and the C runtime environment (located in low memory), and
>the
>> > stack.
Not always. Some heaps are implemented entirely in a different address
space than your program. Indeed, there's nothing that says that you
can't have an address space for your code, another for your static
data, a third for your stack, and a fourth for your heap. Or not.
>>
>> Again, the Standard neither requires nor even mentions this.
>
>Once again, whether the "Standard" mentions it or not there is, in most
>cases at least, free memory. Where else could dynamic memory allocations
>come from, the hard drive?
Certainly.
That's where my system's virtual memory resides. I certainly don't
have 300 Mb of real memory on my system even though the programs think
that there's that around. And on the mainframe I work on, there's
Gigabytes more virtual (DASD) memory than real memory.
>This free memory is affectionately known as the
>heap.
Nope. 'heap' is a reference to a particular data management technique,
and doesn't mean 'the free memory in the system'.
>Perhaps the Standard does mention it but is is kinda funny how many
>textbooks and other electronic media do.
Gee. I guess that makes the standard wrong, doesn't it?
>
>>
>> C doesn't have an alloc() function.
>>
>
>Oops, that was a typo -- was supposed to be malloc( )
Lew Pitcher
Information Technology Consultant
Toronto Dominion Bank Financial Group
(Opinions expressed are my own, not my employer's.)
Dann Corbit
news:mo675.2395$7%3.20...@news.flash.net...
>
> Richard Heathfield <bin...@eton.powernet.co.uk> wrote in message
> news:395CE795...@eton.powernet.co.uk...
> > Clark wrote:
>
> > This is not necessarily true. The Standard doesn't even mention the word
> > "stack".
>
> Mentioned, or not, where do the return addresses go when a series of
> little data structure in memory which is affectionately known as the
stack.
There are some machines which don't have stacks. All we should need to care
about is what the standard has to say. For instance:
[#5] An instance of each object with automatic storage
duration is associated with each entry into its block. Such
an object exists and retains its last-stored value during
the execution of the block and while the block is suspended
(by a call of a function or receipt of a signal).
The mechanism for how this happens is irrelevant.
> > > The stack usually starts at the highest
> > > memory address and grows downward.
> >
> > On your system. How about an IBM mainframe? What about a Palm III? Atari
> > ST? A Vax?
>
> Granted!
>
> > > The heap, on the other hand, is the remaining memory that resides
> between
> > > your program and the C runtime environment (located in low memory),
and
> the
> > > stack.
> >
> > Again, the Standard neither requires nor even mentions this.
>
> Once again, whether the "Standard" mentions it or not there is, in most
> cases at least, free memory. Where else could dynamic memory allocations
> come from, the hard drive?
Of course.
C:\tmp>type foo.c
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
char *foo = malloc(150000000L);
if (foo) {
puts("Allocated 150 megabytes on a machine with 128 megs ram");
free(foo);
}
return 0;
}
C:\tmp>cl /W4 /Ox /Za foo.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
foo.c
Microsoft (R) Incremental Linker Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
/out:foo.exe
foo.obj
C:\tmp>foo
Allocated 150 megabytes on a machine with 128 megs ram
bash-2.02$ gcc -Wall -ansi -pedantic foo.c
bash-2.02$ cat foo.c
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
char *foo = malloc(150000000L);
if (foo) {
puts("Allocated 150 megabytes on a machine with 128 megs ram");
free(foo);
}
return 0;
}
bash-2.02$ ./a
Allocated 150 megabytes on a machine with 128 megs ram
bash-2.02$
Where do you suppose that extra (150-128) megs of memory came from? That's
right. From the hard disk. Unix, OpenVMS, MVS -- why even Windows 32
operating systems -- all do this.
> This free memory is affectionately known as the
> heap.
To those unfamiliar with the correct terminology.
> Perhaps the Standard does mention it but is is kinda funny how many
> textbooks and other electronic media do.
It's funny how many people will read a Schildt book and think they know the
language.
> >
> > C doesn't have an alloc() function.
> >
>
> Oops, that was a typo -- was supposed to be malloc( )
Neither the words "heap" nor "stack" occur in the C standard. Your
implementation may use this terminology. People will generally understand
what you are talking about. But the names of the data structures used to
allocate memory are not important.
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. Newsgroup http://www.dejanews.com/~c_a_p
C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm
Steven Huang
> Richard Heathfield <bin...@eton.powernet.co.uk> wrote in message
> news:395CE795...@eton.powernet.co.uk...
> > Clark wrote:
> > This is not necessarily true. The Standard doesn't even mention the word
> > "stack".
> Mentioned, or not, where do the return addresses go when a series of
> functions is called. They don't go in registers do they? They go into a
> little data structure in memory which is affectionately known as the stack.
This is from rusty memory, so it might be inaccurate in certain areas.
The Sun SPARC has a feature called a register file or something, which
basically presents the program with three sets of registers. I'll call
them i0..i31 (I don't remember the precise number), r0..r31, and o0..o31.
The i0..i31 registers are used to pass parameters to the running code,
the r0..r31 registers are for your temporary use, and the o0..o31
registers are for calling other functions.
When you generate (hypothetical assembly) code like this:
MOVE 3, o0
MOVE 4, o1
MOVE 5, o2
CALL foo
what happens when the function foo() is called is that the o0..o2
registers are now automagically known as the i0..i31 registers to
foo(). So you might write foo() like so:
foo:
ADD i0, i1, r0
ADD r0, i2, r1
MOVE r1, i0 ; return value in i0
RET
foo() can then call other functions using its own o0..o31 registers,
and so on. Of course, the register file is of finite size, and if
you recurse too deeply it will "swap" to memory.
As you may have guessed, this feature avoids having to move useful
values in registers around just so you could call another function.
[...]
> > > The heap, on the other hand, is the remaining memory that resides
> > > between your program and the C runtime environment (located in low
> > > memory), and the stack.
> > Again, the Standard neither requires nor even mentions this.
> Once again, whether the "Standard" mentions it or not there is, in most
> cases at least, free memory. Where else could dynamic memory allocations
> come from, the hard drive?
[...]
Yes. Swap space!
In more detail, even when there exists "remaining memory", such memory
does have to be physically or logically "between" your program and the
stack. As an example, given a 32-bit address space, the compiler can
locate your program starting at 0, the stack at 2GB growing downwards,
and the freestore at 2GB to 4GB. There's no need to fill the "holes"
that are not actually used with real memory.
Don't take this as picking a fight, but our own views of the world are
often incomplete, so we need to be careful when generalizing.
Chris Torek
>>The stack usually starts at the highest memory address and grows downward.
In article <395CE795...@eton.powernet.co.uk>
Richard Heathfield <bin...@eton.powernet.co.uk> writes:
>On your system. How about an IBM mainframe? What about a Palm III? Atari
>ST? A Vax?
Well, he did say "usually", and I realize the above were probably
meant rhetorically, but just for fun: Typically, IBM mainframe
systems tend to use linked lists of what most of us consider
"heap-allocated" frames for their "stack" frames, in languages
where recursion is allowed.
The Palm III uses a microprocessor with conventional "stack" behavior
(I think the III is 680x0-based, in fact, but I have never looked
inside one; this is just vague memory). The Atari is similar. By
convention only, 680x0 machines use the a6 register as a frame
pointer, and a7 (aka "sp") as a stack pointer. The "link" and
"unlink" instructions use "sp" implicitly.
The VAX actually has an architectural division in its address space.
Addresses between 0 and 0x3fffffff are in "P0 space"; addresses in
the range 0x40000000 through 0x7fffffff are in "P1 space"; and
addresses in 0x80000000 through 0xbfffffff are in "system" space.
(Addresses above 0xc0000000 are illegal.) VMS uses the P1 space
in odd ways (including as "stack"), while most other systems treat
P0 as "text+data" and P1 as "stack". The VAX itself has dedicated
"stack pointer" and "frame pointer" registers, as well as an
"argument pointer" register for function-call arguments, which are
used in special ways by the CALLS and RET instructions.
So, three of the four machines mentioned do in fact have stacks
that grow downward. On the other hand, Unix-like systems tend to
stuff "interesting" things above the top of the user stack, and
of course the VAX has kernel-space addresses above all user-space
addresses.
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA, USA Domain: to...@bsdi.com +1 510 234 3167
http://claw.bsdi.com/torek/ (not always up) I report spam to abuse@.
Chris Torek
Lew Pitcher <Lew_P...@tdgroup.com> writes:
>... Indeed, there's nothing that says that you
>can't have an address space for your code, another for your static
>data, a third for your stack, and a fourth for your heap. Or not.
C is not as "friendly" to this technique as (e.g.) Standard Pascal.
(Standard Pascal has, or had when I used Pascal in the early 1980s
anyway, no address-of operator.) In particular, if you have a bit
of C code such as:
int foo(char **p) {
*p = "hello world";
return 3;
}
and the system likes to put distinct storage-lifetimes (auto vs static
vs "malloc"/heap/whatever-you-call it) into distinct address spaces,
then since foo() can be called as:
void A() {
char *s;
foo(&s);
...
}
void B() {
static char *s;
if (s == NULL)
foo(&s);
...
}
void C() {
char **sp;
sp = malloc(sizeof *sp);
if (sp == NULL) panic(...);
foo(sp);
...
}
the compiler must do something so that foo() will work in all three
cases. (The most likely way is to implement foo() such that it
loads an "address space" register as well as the "pointer" and then
uses some kind of "store to space+pointer" instruction.)
In short, it *is* allowed, but it is not terribly common, if only for
efficiency reasons.
>Nope. 'heap' is a reference to a particular data management technique,
>and doesn't mean 'the free memory in the system'.
This is a bit of a problem: different people use computer terminology
differently. People do in fact use "the heap" to refer to what
the C99 standard calls "allocated storage duration" space. Other
people use the word "heap" to refer to a tree-like data structure
that meets the constraint: value(node) > max(value(leftchild(node)),
value(rightchild(node))). The standard seems to lack a shorter
name for "memory whose lifetime is that of allocated storage
duration". I think "malloc arena" is unambiguous, but is still
less wieldy than a nice pithy term like "heap". People want a
pithy term; it would be nice if the standard provided one. "Heap"
is probably out, due to its other meaning (the tree-like data
structure).
Dann Corbit
Dann Corbit
'Allocated' memory
'Automatic' memory (or just auto if you hate typing)
Some like the term "free store."
I don't.
No need to get fancy.
The standard generally calls allocated memory "allocated memory" which I
find rather refreshing. And it consistently uses the terminology "automatic
storage" for automatic storage. Such a concept.
;-)
Keith Thompson
> For memory usage terms, how about:
> 'Allocated' memory
> 'Automatic' memory (or just auto if you hate typing)
"Allocated memory" refers to memory that has been allocated by *alloc
(and has not been free()ed), yes? The term "heap" refers (in certain
implementations) to a region of memory that has been *or could be*
allocated by *alloc. In other words, the "heap" is typically
allocated memory plus allocatable memory.
--
Keith Thompson (The_Other_Keith) k...@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.
Dann Corbit
news:yechfaa...@king.cts.com...
> "Dann Corbit" <dco...@solutionsiq.com> writes:
> > For memory usage terms, how about:
> > 'Allocated' memory
> > 'Automatic' memory (or just auto if you hate typing)
>
> "Allocated memory" refers to memory that has been allocated by *alloc
> (and has not been free()ed), yes? The term "heap" refers (in certain
> implementations) to a region of memory that has been *or could be*
> allocated by *alloc. In other words, the "heap" is typically
> allocated memory plus allocatable memory.
Heap is a data structure that lazy people sort with. But I guess if you
just have to name the pile something, maybe that's why they invented the
term "free store."
Many memory allocation schemes don't use heaps at all. Circular queues are
one particular method I have seen. Why call it a heap if it may or may not
be a heap?
But then, we call qsort() quick sort frequently, when usually it isn't (or
at least, it isn't an unmodified Hoare's quick sort or even quicker sort
which would also start with a 'q'). Typically, qsort is actually
implemented as one of:
Singleton's sort
Heap sort
Introspective sort
Just sort() would have been a much better name.
Meanwhile, back at the farm, it may or may not be a heap. If you call it a
heap, people will know what you are talking about, but a misnomer is still a
misnomer. Why is it necessary to name the place it comes from? The same
nonsense makes people call auto's "stack frame variables" which they may or
may not be.
"I malloced memory from the heap" adds absolutely no information to the
phrase "I malloced memory."
"I created an auto on the stack." adds absolutely no information to the
phrase "I created an auto."
If anything, they add misinformation.
Clark
it's been over 3 years since I have even done C, and even then, it was in
very specific environments.
As for you Mr. Corbit, I have never read a Schildt book in my life.
However, I did take C and "Data Structures in C" in college, and I used it
in many of my other (EE) classes, not to mention the fact that that was all
that I did for a living for about 5 years preceding the 3+ years of my
absence from it. But again, my environments were limited to DOS and
embedded 8032's. The only reason I have been frequenting this room of late,
is I will soon be needing C once again when we switch from the 68HC11 to
the Atmel AVR microcontrollers, and I am trying to get back where I was.
However, I promise to never again comment on anything of the magnitude of
stacks and floats.
And I know you don't care Mr. Corbit, but just FYI, although everyone talks
about the holy Standard in here, I am a EE programming microcontrollers, and
I am not writing any code that has to be ported anywhere, or interact with
any other persons code except my associates, so I don't really give a crap
about the Standard. However, as they say, when in Rome, do as the Romans
do, so I will never again comment about anything that I am not sure is the
Standard in here.
Mr. Corbit, I shall await your no-doubt forthcoming scathing reply. But try
to remember in the future, there are always nice ways to "put someone in
their place", as Mr. Huang has demonstrated. Perhaps my reply wasn't
entirely correct, but I didn't deserve your attitude, and I didn't start
this one bud.
regards,
clark
Dann Corbit <dco...@solutionsiq.com> wrote in message
news:io775.1131$Ga3.1225@client...
> "Clark" <cl...@contemporaryresearch.com> wrote in message
> news:mo675.2395$7%3.20...@news.flash.net...
> >
> > Richard Heathfield <bin...@eton.powernet.co.uk> wrote in message
> > news:395CE795...@eton.powernet.co.uk...
> > > Clark wrote:
> >
> > > This is not necessarily true. The Standard doesn't even mention the
word
> > > "stack".
> >
> > Mentioned, or not, where do the return addresses go when a series of
> > functions is called. They don't go in registers do they? They go into
a
> > little data structure in memory which is affectionately known as the
> stack.
>
> There are some machines which don't have stacks. All we should need to
care
> about is what the standard has to say. For instance:
>
> [#5] An instance of each object with automatic storage
> duration is associated with each entry into its block. Such
> an object exists and retains its last-stored value during
> the execution of the block and while the block is suspended
> (by a call of a function or receipt of a signal).
>
> The mechanism for how this happens is irrelevant.
>
> > > > The stack usually starts at the highest
> > > > memory address and grows downward.
> > >
> > > On your system. How about an IBM mainframe? What about a Palm III?
Atari
> > > ST? A Vax?
> >
> > Granted!
> >
> > > > The heap, on the other hand, is the remaining memory that resides
> > between
> > > > your program and the C runtime environment (located in low memory),
> and
> > the
> > > > stack.
> > >
> > > Again, the Standard neither requires nor even mentions this.
> >
> > Once again, whether the "Standard" mentions it or not there is, in most
> > cases at least, free memory. Where else could dynamic memory
allocations
> > come from, the hard drive?
>
Tor Rustad
| Hi,
|
| What is the difference between the stack and heap?. How do we place
| the different variables in these locations?. Compiler does it for us
| Do we specify the location on their labels or someone who is doing
| it knows where to put them?. I know this is a silly way to put it
| but I am trying my best.
|
The implementation of C run-time storage organization is implementation defined.
For run-time memory we can have
+-------------+
| Code |
+-------------+
| Static data |
+-------------+
| Stack |
+-------------+
| grow down |
| |
| grow up |
+-------------+
| Heap |
+-------------+
but this is completely implementation dependent. This is an abstract view of
memory, the OS/ MMU controls what physical adresses it mapps to, it may be in
RAM, ROM, EEPROM, swap/pagefile, ...
Futhermore, heap allocation and deallocation strategy is different among the
implementations. Hence, it is wrong to state "heap is a last-in-smallest-out
data structure".
Using a best fit strategy will hurt performance, while using first fit will
waste space. Hence, there is a trade off, and real life implementations will
very much optimize their strategy.
Unless you are into writing advanced programs, these sort of things is handled
for you. The exeception is the stack, which is a useful data structure in many
simple applications aswell.
--
Tor
Richard Heathfield
>
> [name filed off]
> >>The stack usually starts at the highest memory address and grows downward.
>
> Richard Heathfield <bin...@eton.powernet.co.uk> writes:
> >ST? A Vax?
>
> meant rhetorically,
Yes, they were. I knew about the mainframe myself, and would have been
prepared to take a good guess on the Palm and the ST (which are both
680x0 based, as you correctly say).
But my point was simply that not all the world is a PC.
> So, three of the four machines mentioned do in fact have stacks
> that grow downward.
Ah well, that's what happens when one picks examples at random. :-)
Keith Thompson
> "Keith Thompson" <k...@cts.com> wrote in message
> news:yechfaa...@king.cts.com...
> > "Dann Corbit" <dco...@solutionsiq.com> writes:
> > > For memory usage terms, how about:
> > > 'Allocated' memory
> > > 'Automatic' memory (or just auto if you hate typing)
> >
> > "Allocated memory" refers to memory that has been allocated by *alloc
> > (and has not been free()ed), yes? The term "heap" refers (in certain
> > implementations) to a region of memory that has been *or could be*
> > allocated by *alloc. In other words, the "heap" is typically
> > allocated memory plus allocatable memory.
>
> Heap is a data structure that lazy people sort with. But I guess if you
> just have to name the pile something, maybe that's why they invented the
> term "free store."
>
> Many memory allocation schemes don't use heaps at all. Circular queues are
> one particular method I have seen. Why call it a heap if it may or may not
> be a heap?
Unfortunately, there are at least two entirely distinct meaning for
the word "heap".
One meaning is a particular data structure, a binary tree that
satisfies certain conditions and can be easily represented as a linear
array. See Knuth volume 3, for example.
Another meaning is the region of memory from which objects can be
dynamically allocated. For example, in Hennesy & Pattern's "Computer
Architecture, a Quantitative Approach", 2nd edition, page 93:
The heap is used to allocate dynamic objects that do not adhere to
a stack discipline. Objects in the heap are accessed with
pointers and are typically not scalars.
As far as I can tell, both meanings are equally valid. Probably they
were independently derived from the common English meaning, and the
originator of each had never heard of the other usage at the time the
terms were invented. Both meanings are thoroughly entrenched in the
language.
I can't find any reference to either "heap" or "free store" in the C90
standard, in the n689 draft of C9X, in K&R, in H&S, or in the C FAQ.
I agree that if you're going to be maximally precise (which of course
we should be in this newsgroup), it's probably best not to refer to
"the heap" -- both because of possible confusion with the data
structure and because it implies certain mechanisms for memory
management.
Nevertheless, many (most?) programmers commonly think of malloc() as
allocating memory from "the heap" and free() as returning memory to
"the heap". If we're going to steer them in the direction of greater
precision when they post here, we need to understand what they mean.
Furthermore, although "the heap" is not a universal concept, it's a
very useful one for those systems where it's applicable.
Orin Harrison
Martin Ambuhl
Orin Harrison wrote:
>
> As usual Richard, you have done little to answer the original question.
As usual, people who criticize Richard have fewer clues than GW Bush.
The original question has been answered in much more depth than it deserves to
be. It was about implementation details that are off-topic here. Richard has
provided a gloss on some of the discussion that has evolved from this
off-topic question. If he has erred, it is by giving too much attention to
this question, not too little.
Jack Klein
<cl...@contemporaryresearch.com> wrote in comp.lang.c:
As someone who has been programming microcontrollers and
microprocessors in embedded systems for more than 20 years I think
your attitude is foolish at best.
I don't mean your attitude towards Dann, he's a big boy and he can
take care of himself.
I do mean your attitude towards the C standard. The more programming
one does on non-standard platforms making use of hardware specific
features, the more one needs to know about the C standard.
I often work on code for various 8, 16, and 32 bit embedded systems in
the same week, sometimes even all in the same day. I would be foolish
indeed if I did not know what code was Standard C and worked on all
implementations, as opposed as to what was compiler or processor
specific.
> The stack is a LIFO (last-in, first-out) data structure, used for things
> like passing parameters to function calls and returning the value of a
> function call (dependent, of course, on the calling convention either
> implicitly or explicitly specified), storing the return address of the
> calling function during a function call such that the called function can
> return to the proper place, etc. The stack is created by the compiler, and
> maintained by the C runtime environment. I don't recall any functions in C
> that let you directly manipulate the stack (although I could be wrong, I
> have been away from C for awhile). The stack usually starts at the highest
> memory address and grows downward.
Since you claim to be an experienced 8051 programmer, I find the above
quotation from your earlier post to be really surprising. No 8051
compiler that I know of actually places function call parameters,
return values, or local variables on the processor stack, due to its
extremely limited size (less than 60 bytes available on some
derivatives!). And surely you know, if you know anything about the
8051 architecture at all, that the hardware stack builds from low to
high addresses in that family, no matter what the compiler wants it to
do.
Jack Klein
--
Home: http://jackklein.home.att.net
studpup
> I do mean your attitude towards the C standard. The more programming
> one does on non-standard platforms making use of hardware specific
> features, the more one needs to know about the C standard.
With all due respect, I think that is one of the silliest, most
contradictory things I have ever heard.
> Since you claim to be an experienced 8051 programmer, I find the above
> quotation from your earlier post to be really surprising. No 8051
> compiler that I know of actually places function call parameters,
> return values, or local variables on the processor stack, due to its
> extremely limited size (less than 60 bytes available on some
> derivatives!). And surely you know, if you know anything about the
> 8051 architecture at all, that the hardware stack builds from low to
> high addresses in that family, no matter what the compiler wants it to
> do.
Actually my friend, the 8051 family has been 3+ years too, so im a little
rusty; forgive me. At the current time I am doing mostly Visual Basic for
the PC, which I despise, being of the anti-Windows mindset that I am, with
68HCxx Assembly on the side. But as I remember, I am not referring to a
hardware stack, but rather a software stack that the Keil/Franklin compiler
sets up automatically, unless you specifically go into the self-created
module and turn it off.
no hard feelings,
-clark
studpup
shall do that now.
studpup <stu...@hotmail.com> wrote in message
news:8jlp8i$g...@library1.airnews.net...
Dik T. Winter
> Chris Torek wrote:
> > >On your system. How about an IBM mainframe? What about a Palm III? Atari
> > >ST? A Vax?
> >
> > Well, he did say "usually", and I realize the above were probably
> > meant rhetorically,
>
> Yes, they were. I knew about the mainframe myself, and would have been
> prepared to take a good guess on the Palm and the ST (which are both
> 680x0 based, as you correctly say).
Being 680x0 based does not necessarily mean that they work indeed the same.
For instance the Alliant (now quite some years defunct) was basically a
680x0 wich vector instructions and thread instructions added. That machine
used what was called a "cactus stack". Like the IBM for each routine call
a stack frame was allocated from free memory. Normally routines that
called each other would have adjacent stack frames, but they grew upward,
in when threads were used new stack frames could be everywhere.
studpup
here has to have the last word huh? Everyone has to prove how much smarter
they are then the next guy, huh? Well thanks yall, you are all FUCKING
geniouses.
and damn, i thought newsgroups were supposed to be for similar people with
similar tastes or ideas to share with each other, maybe even help each
other. i never realized, until now, that it is a competition. thanks for
shedding the light.....
well im just a little dummy software engineer (but i will kick your ass in a
calculus test any day), and i obviously cant compete with all you smart
people/ you dont like my misuse of capital lettrers fuck you.........
you dont like my use of periods????? fuck you...... this is a room i dont
like, and i will not be back......
AND SPECIFICALLY FOR YOU MR CORBIT!!!!!!!!! FUCK YOUUUUUUU!!!!!
<jack...@hotmail.com> wrote in message news:8jigkf$e33$1...@nnrp1.deja.com...
> Hi,
>
> What is the difference between the stack and heap?. How do we place
> the different variables in these locations?. Compiler does it for us
> or we have to specify it?. Like, taking bunch of stuff to an house.
> Do we specify the location on their labels or someone who is doing
> it knows where to put them?. I know this is a silly way to put it
> but I am trying my best.
>
>
> jack...@hotmail.com
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
studpup
program yourself out of a box........
studpup <stu...@hotmail.com> wrote in message
news:A57C499AFA89C29F.D1CD4B03...@lp.airnews.net...
Selim Levy
<snip a whole lot of mindless drivel>
I didn't join this thread, mostly because it is not in my field of
knowledge. One thing is clear to me, though: regardless under what name
studpup writes, the contents are equally not fit for clc. I had
*plonked* him some time ago under his studpup name (and never unplonked
him, despite his apology), and I now feel obliged to carry this
tradition on to his new id.
Studpup: please understand that I by no means take offence to your
(apparent) lack of knowledge, which Mr. Klein pointed out in a parallel
thread; I am far from being a guru myself. However, this being a
technical forum, I don't see why users should try to impress others
simply by using technical terms of which they have to clue (other than
to ask a question, of course). And upon being corrected, instead of
being thankful for someone's courtesy in helping the learning process,
these same users take offence that anybody dares, on a public discussion
forum, point out the flaws. Newsgroups are not a private discussion
between two poeple -- thousands, if not more, people read/parttake in
threads here. Would it be right to deny them quality information or,
even worse, give them blatantly false information? I think not.
*plonk*
--
"They are multiplying like flies. Let's be like happy baby maggots and
crawl all over them, licking up the filthy data they so lovingly
provide. Our bulging tummies and smiling faces will shine like a fat
turnip in the garden of life."
- Dann Corbit on comp.lang.c about search engines 2000-05-25
Richard Heathfield
>
> this has gone past simple amusement,
I have yet to see any amusement in this thread.
> to pure ridicularity.
If you mean you're being ridiculous, you're right. People would be
laughing at you, if they weren't busy either pitying you, plonking you,
or both.
> So everyone in
> here has to have the last word huh?
It certainly seems that you want the last word. But, you see, the last
word is irrelevant. What matters is that people are not misled by
inaccurate information.
> Everyone has to prove how much smarter
> they are then the next guy, huh?
No. Most people strive for the truth. You seem to be trying (and
failing) to prove that you're smarter than others. You'll never achieve
that by swearing at people.
> Well thanks yall, you are all FUCKING geniouses.
(sigh) No, the vast majority of people who read comp.lang.c, including
me, are not geniuses. We are just people who want to learn more about C.
There's a very small number of extraordinarily clever people here, and
perhaps a genius or two amongst them, who give much more to comp.lang.c
than they could possibly take from it, even though periodic idiocies
such as yours sour the flavour of the newsgroup from time to time.
>
> and damn, i thought newsgroups were supposed to be for similar people with
> similar tastes or ideas to share with each other, maybe even help each
> other.
I can't answer for other newsgroups, but this newsgroup is for
discussing the C programming language. The words "stack" and "heap" are
not even mentioned in the C Standard, as I have already pointed out, so
this whole thread doesn't belong in comp.lang.c at all.
> i never realized, until now, that it is a competition.
Some people seem to think it /is/ a competition, but not many. Most of
us are here to learn more about C.
Do you know how you can spot the people who think it's a competition?
They're the ones that explode in anger when someone points out they're
wrong. Now go look in a mirror.
> thanks for shedding the light.....
It is my pleasure to point out these little matters for your attention.
Thanks are entirely unnecessary. Simple civility, however, would make a
pleasant change to your usual foul-mouthed ramblings.
>
> well im just a little dummy software engineer (but i will kick your ass in a
> calculus test any day),
Don't make me laugh. There are people here who've been using calculus in
their daily jobs since way before it was invented. And, in case you
don't recognise hyperbole when you see it, the previous sentence
employed hyperbole as a debating technique.
> and i obviously cant compete with all you smart
> people/
Why would you want to? comp.lang.c is not a contest.
> you dont like my misuse of capital lettrers fuck you.........
Appropriate use of the language smooths communication. Use of expletive
is a good indication that you've lost the plot.
> you dont like my use of periods????? fuck you...... this is a room i dont
> like, and i will not be back......
You won't be missed.
>
> AND SPECIFICALLY FOR YOU MR CORBIT!!!!!!!!! FUCK YOUUUUUUU!!!!!
This is the biggest clue of all that you've lost the plot. Dann is one
of the more helpful posters (not, it has to be said, the /most/ helpful,
but certainly up there in the leading pack) in comp.lang.c. Yet you
single him out for specific abuse. I had read your apology for "posting
while drunk" with considerable interest. I believed that you intended
that apology sincerely. I was wrong.
You go right back into the killfile, and this time there's no escape.
Ever.
studpup
now let me see if i can find the"plonk" to a newsgroup. oh, here it
is........
Richard Heathfield <bin...@eton.powernet.co.uk> wrote in message
news:395EE00C...@eton.powernet.co.uk...
Martin Ambuhl
studpup wrote:
>
> this has gone past simple amusement, to pure ridicularity. So everyone in
> here has to have the last word huh? Everyone has to prove how much smarter
> they are then the next guy, huh? Well thanks yall, you are all FUCKING
> geniouses.
I don't know about that, but you are definitely a foul-mouthed idiot.
Tor Rustad
Chris Mears
the following:
>youre a funny little smart-ass boy heathfield. you actually made me laugh.
>now let me see if i can find the"plonk" to a newsgroup. oh, here it
>is........
Thank the lord for that.
--
Chris Mears
ICQ: 36697123
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Bryan Williams
> On Sun, 2 Jul 2000 03:59:38 -0500, that hoopy frood studpup scribbled
> the following:
May we assume that your newsreader needs a little tweaking ?
--
Bryan Williams
"Of all the things I have lost I miss my mind the most."
- Ozzy O.
Chris Mears
scribbled the following:
>Chris Mears wrote:
>
>> On Sun, 2 Jul 2000 03:59:38 -0500, that hoopy frood studpup scribbled
>> the following:
>
>May we assume that your newsreader needs a little tweaking ?
Do you mean the time or the introduction message?
Bryan Williams
> On Sun, 02 Jul 2000 11:15:25 +0000, that hoopy frood Bryan Williams
> scribbled the following:
>
> >Chris Mears wrote:
> >
> >> On Sun, 2 Jul 2000 03:59:38 -0500, that hoopy frood studpup scribbled
> >> the following:
> >
> >May we assume that your newsreader needs a little tweaking ?
>
> Do you mean the time or the introduction message?
Yes :)
(The hoopy frood bit, as your newsreader has clearly made a mistake)
Richard Heathfield
>
> Chris Mears wrote:
>
> > On Sun, 02 Jul 2000 11:15:25 +0000, that hoopy frood Bryan Williams
> > scribbled the following:
> >
> > >Chris Mears wrote:
> > >
> > >> On Sun, 2 Jul 2000 03:59:38 -0500, that hoopy frood studpup scribbled
> > >> the following:
> > >
> > >May we assume that your newsreader needs a little tweaking ?
> >
> > Do you mean the time or the introduction message?
>
> Yes :)
>
> (The hoopy frood bit, as your newsreader has clearly made a mistake)
>
(Chris, Don't Panic. Mr W is just concerned about the words "hoopy" and
"frood" in relation to studpup.)
I'm not entirely convinced that I want my newsreader passing value
judgements on people to whose articles I wish to respond. I do see your
point, of course, but there is a limit to artificial intelligence.
Natural stupidity, on the other hand, seems to be thriving, though
fortunately it's a relatively small problem in comp.lang.c.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
52 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (45
to go)
Chris Mears
Heathfield scribbled the following:
>Bryan Williams wrote:
>>
>> Chris Mears wrote:
>>
>> > On Sun, 02 Jul 2000 11:15:25 +0000, that hoopy frood Bryan Williams
>> > scribbled the following:
>> >
>> > >Chris Mears wrote:
>> > >
>> > >> On Sun, 2 Jul 2000 03:59:38 -0500, that hoopy frood studpup scribbled
>> > >> the following:
>> > >
>> > >May we assume that your newsreader needs a little tweaking ?
>> >
>> > Do you mean the time or the introduction message?
>>
>> Yes :)
>>
>> (The hoopy frood bit, as your newsreader has clearly made a mistake)
>>
>
>(Chris, Don't Panic. Mr W is just concerned about the words "hoopy" and
>"frood" in relation to studpup.)
Yep, got it now. :)
>I'm not entirely convinced that I want my newsreader passing value
>judgements on people to whose articles I wish to respond. I do see your
>point, of course, but there is a limit to artificial intelligence.
>Natural stupidity, on the other hand, seems to be thriving, though
>fortunately it's a relatively small problem in comp.lang.c.
While my newsreader might not be an accurate judge of character, its
killfile certainly does a sufficient job of weeding out the natural
stupidity, leaving only the natural comp.lang.c brilliance to shine in
its full glory.
Jack Klein
wrote in comp.lang.c:
>
> > I do mean your attitude towards the C standard. The more programming
> > one does on non-standard platforms making use of hardware specific
> > features, the more one needs to know about the C standard.
>
> With all due respect, I think that is one of the silliest, most
> contradictory things I have ever heard.
[snip]
> no hard feelings,
> -clark
If you claim to be a professional, or even serious, C programmer and
believe that you have no need to know and understand the actual
definition of the language, you are mistaken in my opinion.
You are of course entitled to your own opinion, but I can guarantee
that you will never work on a project with me given that attitude.
Nor would you ever work for the same company as any type of developer
or engineer if I had anything to say about it, and I usually do.
Dann Corbit
On second thought, I doubt it.
*plonk*
Steven Huang
[...]
> And I know you don't care Mr. Corbit, but just FYI, although everyone talks
> about the holy Standard in here, I am a EE programming microcontrollers, and
> I am not writing any code that has to be ported anywhere, or interact with
> any other persons code except my associates, so I don't really give a crap
> about the Standard.
You may find that you're doing yourself a disservice this way. Here are
some reasons why you should care:
1. The need to port code is often unexpected. Your compiler vendor
might go out of business. Your hardware vendor might go out of
business. These are variables beyond your control, yet can affect
your project in significant ways if you're caught unprepared.
2. The more standards-compliant (not limited to the C Standard, but
standards in general) your code is, the easier you will find
programmers to staff your project.
3. The more you know about standards-compliant programming, the wider
your own choice of jobs, should you want a change.
Frequently, non-standard code don't need to be. Are you really saying
that, for those instances, you would rather not do the right thing?
That is, are your personal standards of excellence merely that it
compiles and appears to work? That's just hard to believe.
As for this newsgroup, my personal goal here is to learn, so I don't
really care about the attitude that might accompany knowledge. I just
pick up the knowledge. :) I'm not nice, which is why I needed the
disclaimer when I responded to your post.
Cheers. :)
Charlton Wilbur
> > I do mean your attitude towards the C standard. The more programming
> > one does on non-standard platforms making use of hardware specific
> > features, the more one needs to know about the C standard.
>
> With all due respect, I think that is one of the silliest, most
> contradictory things I have ever heard.
Hardly. It might be the case when you work only one one non-standard
platform; as we've seen from the numerous Windows-centric questions here,
if you only work with Windows, you only need to worry about what your
particular compiler does. But if you alternate among various platforms
and various compilers, you need to know what's standard and what's not.
This is not to say that you shouldn't use non-standard extensions to the
language; this is to say that you need to know what is standard and what
is an extension, so that when you move to a different platform you know
what you can rely on to work.
Charlton
--
Charlton Wilbur | Wer bin ich, waer' ich deine Wille nicht?
University of Massachusetts | -- Bruennhilde
cwwi...@music.umass.edu | 1832 - 1841 - 1976 - 1992 - 2001
Steven Huang
> On Sat, 1 Jul 2000, studpup wrote:
> > > I do mean your attitude towards the C standard. The more programming
> > > one does on non-standard platforms making use of hardware specific
> > > features, the more one needs to know about the C standard.
> > With all due respect, I think that is one of the silliest, most
> > contradictory things I have ever heard.
> Hardly. It might be the case when you work only one one non-standard
> platform; as we've seen from the numerous Windows-centric questions here,
> if you only work with Windows, you only need to worry about what your
> particular compiler does.
[...]
Even this is often just an excuse from lazy programmers.
Given a sizable program, how many programmers can honestly say they have
evaluated the practical reusability (I'll tentatively define that as the
market available on other platforms) of every fragment of their program?
That is, your Windows Uninstaller application might not ever be ported
to Unix, but the linked list library embedded in it might well be usable
in an entirely different project elsewhere. One advantage of the attitude
noted by the first quoted paragraph above (Jack Klein, I believe) is that
self-contained libraries can be reused in various platforms.
C doesn't have a Standard Template Library like C++, but I consider it
a failure if a programmer has to rewrite similar functions for each
platform and project. Rewriting existing libraries can become a
significant portion of the total cost, especially when the project is
modest.
Steve McConnell, I believe, recalled in "Writing Solid Code" the attitude
of some Microsoft programmers that Microsoft C wouldn't dare change
the int type to 32-bits and break their assumptions. The C compiler
people, of course, had other customers to attend to, and competition who
were offering 32-bit compilers. That anecdote was entitled something like
"Owning the compiler is not enough".
I am in general agreement with you otherwise. :)
Michael Powe
Hash: SHA1
>>>>> "Keith" == Keith Thompson <k...@cts.com> writes:
Keith> "Dann Corbit" <dco...@solutionsiq.com> writes:
>> Many memory allocation schemes don't use heaps at all.
>> Circular queues are one particular method I have seen. Why
>> call it a heap if it may or may not be a heap?
Keith> Unfortunately, there are at least two entirely distinct
Keith> meaning for the word "heap".
I'm provoked to go through my admittedly limited library and examine
the occurrence of "heap." From the following results, it's pretty
clear that in the context of memory management, "heap" is
well-defined, just as it is in the context of sorting. If heroic
action figures such as Plauger, Tanenbaum, and Stevens can refer to
dynamically-allocatable memory as the "heap," I don't see why the rest
of us, mere mortals that we are, should not do the same.
mp
8<-------------------->8
Dynamic memory allocation in C requires a function call to malloc and
an explicit reference to the sizeof operator (or an explicit mention
of the number of bytes needed). The memory is allocated on the _heap_
(the extra memory available to the program at execution time).
- -- Deitel & Deitel, C How to Program, pp. 576
High-level languages introduced the technique of dynamic memory
allocation (variables created at runtime) quite some time ago. In
Pascal, for instance, pointer variables contain addresses of data that
are dynamically allocated on the _heap_, a special data storage area.
- -- Kip Irvine, Assembly Language for Intel-Based Computers, 3rd ed.,
pp. 517
_Heaps_: Trees organized so that we can determine the node with the
largest value quickly. The cost to preserve this property is less
than that of keeping the data sorted. We can also organize a _heap_
so that we can determine the smallest value just as easily.
- -- Kyle Loudon, Mastering Algorithms With C, pp. 235
A _heap_ is a tree such that every node contains a number that is no
smaller than any of the numbers contained by that node's descendants.
- -- Harbison & Steele, C: A Reference Manual, pp. 77
The _heap_
Static storage remains stable during program execution. Dynamic
storage follows a last-in/first-out discipline. It can be
implemented on a stack. Often, dynamic storage shares the call
stack with function call and return information. ... Allocated
storage follows no such tidy discipline. The program can intermix
the allocation and freeing of such data objects in arbitrary
order. Hence, the Standard C library must maintain a separate
pool of storage called a _heap_ to satisfy requests for controlled
storage.
- -- P. J. Plauger, The Standard C Library, pp. 344
In a _heap_, the records are stored in an array such that each key is
guaranteed to be larger than the keys at two other specific
positions.
- -- Sedgewick, Algorithms in C, 3rd ed., pp. 369
The procedure malloc will allocate storage for a variable and return a
pointer. It is used to create new things out of thin air (actually
out of an area of memory called the _heap_).
- -- Oualline, Practical C Programming, pp. 252
The pool of unallocated memory available to a program is called the
_heap_.
- -- Roberts, Programming Abstractions in C, pp. 88
Still, there is no place to store large arrays or dynamically-created
data structures such as lists or trees. To solve this problem, JVM
contains an extra region of memory, the _heap_, which can be allocated
for storage of dynamic or very large objects.
- -- Tanenbaum, Structured Computer Organization, pp. 317
The _heap_ is a section of RAM set aside for such allocations. In
fact, the _heap_ is what's left of your 640k when all the other memory
demands, such as the OS, STR (terminate and stay resident) programs
and data, and the current program code, data, and stack have been met.
- -- Kelly-Bootle, Mastering Turbo C, pp. 155
* Heap. Dynamic memory allocation usually takes place on the heap.
Historically, the heap has been located between the top of the
uninitialized data and the bottom of the stack.
- -- Stevens, Advanced Programming in the UNIX Environment, pp. 168
8<-------------------->8
- --
"Well, obviously the best programming is LISP." -- Richard Stallman
Michael Powe Portland, Oregon USA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Mailcrypt 3.5.5/GnuPG v1.0.1 http://www.gnupg.org
iD8DBQE5Z+D/755rgEMD+T8RAqoTAJ46s1xXQXXZEo923b5q2P2GGtLnrgCgpnNM
LILOaJK66crnN7cb1Gf5anA=
=n39n
-----END PGP SIGNATURE-----
-hs-
>this has gone past simple amusement, to pure ridicularity. So everyone in
>here has to have the last word huh? Everyone has to prove how much smarter
>they are then the next guy, huh? Well thanks yall, you are all FUCKING
>geniouses.
Do like me, stop drinking. I surived to plain water, and I am fine now.
--
-hs-
CLC-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
ISO-C Library: http://www.dinkum.com/htm_cl
FCLC-FAQ: http://www.isty-info.uvsq.fr/~rumeau/FAQ-FCLC/FAQ-FCLC.html
C-tips: http://jackklein.home.att.net