On Aug 7, 2006, at 5:40 PM, Sam Kong wrote:

> Jeremy Henty wrote:
>> On 2006-08-07, Sam Kong <sam.s.kong / gmail.com> 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