Hello!
I wonder how destructive methods work in the behind.
For example,
s = '12345'
s2 = s
s.sub!('3', 'three')
puts s #->'12three45'
puts s2 #->'12three45'
Destructive methods are in-place.
Does that mean the object doesn't change its location in memory?
Probably not.
I don't think it's possible as the object might need more space and
need to move to a bigger empty space for the changed data.
If it moves, the references pointing to it should be updated as well.
How exactly does that work?
Thanks in advance.
Sam
Just look into string.c in Ruby distribution. It's open source, after all ;-).
Gennady.
···
On Jun 4, 2005, at 12:10, Sam Kong wrote:
Hello!
I wonder how destructive methods work in the behind.
For example,
s = '12345'
s2 = s
s.sub!('3', 'three')
puts s #->'12three45'
puts s2 #->'12three45'
Destructive methods are in-place.
Does that mean the object doesn't change its location in memory?
Probably not.
I don't think it's possible as the object might need more space and
need to move to a bigger empty space for the changed data.
If it moves, the references pointing to it should be updated as well.
How exactly does that work?
Thanks in advance.
Sam
Hi --
Hello!
I wonder how destructive methods work in the behind.
For example,
s = '12345'
s2 = s
s.sub!('3', 'three')
puts s #->'12three45'
puts s2 #->'12three45'
Destructive methods are in-place.
Does that mean the object doesn't change its location in memory?
Probably not.
I don't think it's possible as the object might need more space and
need to move to a bigger empty space for the changed data.
If it moves, the references pointing to it should be updated as well.
The references aren't the same as memory pointers, though. They're a
Ruby language-level concept, probably overlapping with physical memory
allocation a lot of the time but also abstracted away from it. In the
example above, I wouldn't care (except for possible speed
considerations) what was going on with memory management in the
interpreter, as long as I knew that on the Ruby side, I was operating
on a single object and it was behaving accordingly.
David
···
On Sun, 5 Jun 2005, Sam Kong wrote:
--
David A. Black
dblack@wobblini.net
Sam Kong wrote:
Hello!
I wonder how destructive methods work in the behind.
For example,
s = '12345'
s2 = s
s.sub!('3', 'three')
puts s #->'12three45'
puts s2 #->'12three45'
Destructive methods are in-place.
Does that mean the object doesn't change its location in memory?
Probably not.
I don't think it's possible as the object might need more space and
need to move to a bigger empty space for the changed data.
If it moves, the references pointing to it should be updated as well.
How exactly does that work?
Thanks in advance.
Sam
Don't think of an object's id as a memory address. Think of it as a handle for a memory address. That way, if the memory address of an object needs to change (if, for example, Ruby needs to allocate more memory for a string) Ruby can update the id with the new address and the id can remain the same.
Hello Sam,
Hello!
I wonder how destructive methods work in the behind.
For example,
s = '12345'
s2 = s
s.sub!('3', 'three')
puts s #->>'12three45'
puts s2 #->>'12three45'
Destructive methods are in-place.
Does that mean the object doesn't change its location in memory?
Probably not.
I don't think it's possible as the object might need more space and
need to move to a bigger empty space for the changed data.
If it moves, the references pointing to it should be updated as well.
How exactly does that work?
A string is of c type VALUE (as every ruby object). This c type hold
at least 16 byte. So there is enough space to keep a string length and
the pointer inside the object.
···
Thanks in advance.
Sam
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's