richard@SOPHIST.UCHICAGO.EDU (Richard L. Goerwitz III) (05/03/90)
Why is it that a procedure like
procedure return_table()
tbl := table()
return tbl
end
works. I guess I never really thought about it before (I don't
mentally transfer Icon into equivalent constructions in other
languages). If I had no familiarity with Icon, I'd probably way
"make tbl static or global, 'cause it'll disappear when return_
table() returns, and all you'll be left with is a pointer aiming
into the great void."nevin1@ihlpb.att.com (05/04/90)
>Why is it that a procedure like > > procedure return_table() > tbl := table() > return tbl > end > >works. [...] >If I had no familiarity with Icon, I'd probably way >"make tbl static or global, 'cause it'll disappear when return_ >table() returns, and all you'll be left with is a pointer aiming >into the great void." [Side note: the above is a good explanation of a very common C programming error.] The the table sticks around because is it is stored in that area of memory commonly referred to as the "heap". (This is the same type of memory that C's malloc() function returns pointers into.) [Note: there are other ways of implementing call-return mechanisms (eg: copy the object before returning), but they have other problems associated with it.] One purpose of a heap is to have objects survive procedure calls and returns. Like static variables, it has limited visibility. However, it differs from statics in that each call to a function like your return_table() returns a DIFFERENT table each time. (I don't mean to say that if tbl were declared static that the return_table() would return the same table each time; its behavior would not change. What I mean is that in the framework of a language like C, if you return a pointer to a static you will always get the same address, while if you return a pointer to something malloc()ed you will get a different address.) The other purpose to having a heap is to create objects of arbitrary size or of sizes unknown at compile time. I hoped I haven't rambled too long. It's been a long day. :-) NEVIN ":-)" LIBER nevin1@ihlpb.ATT.COM (708) 831-FLYS
langley@DG-RTP.DG.COM (Mark L Langley) (05/04/90)
Richard Goerwitz III asks > > Why is it that a procedure like > > procedure return_table() > tbl := table() > return tbl > end > > works. I guess I never really thought about it before (I don't > mentally transfer Icon into equivalent constructions in other > languages). If I had no familiarity with Icon, I'd probably way > "make tbl static or global, 'cause it'll disappear when return_ > table() returns, and all you'll be left with is a pointer aiming > into the great void." > Ah, this is one of the great things about Icon -- Memory management is done for you. Dynamic storage allocation is the trick. Imagine two ways of using your office, playroom, or kitchen counter. Static Storage Allocation: Take something out, put it back, Take it out, put it back... Dynamic Storage Allocation: Take things out, put them back when you need the space. To make a long story short, the Icon garbage collector is responsible for collecting things that you no longer need. The interpreter doles out memory as needed. When it runs out, it finds all the objects that could still be referenced and moves them together. This writes over all the objects that cannot be reached anymore, leaving space at the end. Between this and saying "Mother may I have some more?" to the operating system, it usually avoids running out of memory. Mark