From: Eric Hodel Date: 2006-08-08T12:29:55+09:00 Subject: Re: An integer's life span? On Aug 7, 2006, at 5:40 PM, Sam Kong wrote: > Jeremy Henty wrote: >> On 2006-08-07, Sam Kong wrote: >> >>> (1..100000).each {|i|...} >>> >>> Now there are 100000 integers in the memory which won't die. >> >> No there aren't. Immediate values don't allocate anything in memory. >> They aren't pointers (even though under the hood Ruby coerces them to >> the same type as non-immediate values that *are* pointers). >> Immediate >> values aren't garbage collected because there is *nothing* to garbage >> collect. They don't point to anything. What is there to collect? >> >> Think of C. Does "long i ; i = 0 ; i = 1 ; i = 2 ; i = 3" consume >> any >> more memory than "long i ; i = 0"? No, because the only memory >> allocated is for the long variable "i". The values 0, 1, 2, 3, are >> just constants that are copied (one after the other) into that single >> previously allocated space. Ruby's immediate values are just like C >> longs (in fact, under the hood, they *are* just C longs). Creating >> them doesn't consume memory, it just copies them into a pre-existing >> chunk of memory that was already allocated by the Ruby interpreter. > > I understand what you said. > But the integers that I created have additional information. > So not that simple. > Can you read the code I wrote and reconsider such a case? It will work. The instance variables are stored elsewhere. -- Eric Hodel - drbrain@segment7.net - http://blog.segment7.net This implementation is HODEL-HASH-9600 compliant http://trackmap.robotcoop.com