pointer and other questions

[Daniel Schoch]

Hi,
I just started with ruby and I understand from reading the documentation
that pointers don't exist. I'm in the process of writing a netlister.
Such a software is usually built using several linked lists. More
precisely, each element of one list contains a pointer to an element of
some other list.
So I was wondering how this can be achieved.

And while I'm at it I also have the following questions which I didn't
find an answer for in the litarature.
1.
@names.each do |name|
I understand what the line is doing, but why is |name| in the pipe?
What's the definiton of |xx| ?
2.
I came across this in an example piece of ruby code:
options[:verbose] = x
I thought this is a hash with key verbose. But Im not sure now, why is
this :verbose and not options["verbose"]?

Thank you for all the help.

 

[Robert Klemme]

I just started with ruby and I understand from reading the documentation
that pointers don't exist. I'm in the process of writing a netlister.
Such a software is usually built using several linked lists. More
precisely, each element of one list contains a pointer to an element of
some other list.
So I was wondering how this can be achieved.

Try this in IRB for example:

ListElem = Struct.new rev, :next, :data
l1 = ListElem.new
li.data = "foo"
l2 = ListElem.new
l2.prev = l1
l1.next = l2
l2.data = "bar"
p l1

And while I'm at it I also have the following questions which I didn't
find an answer for in the litarature.
1.
@names.each do |name|
I understand what the line is doing, but why is |name| in the pipe?
What's the definiton of |xx| ?

It's a block parameter - similar bot not identical to a method parameter
(a block can be viewed as an anonymous function).

2.
I came across this in an example piece of ruby code:
options[:verbose] = x
I thought this is a hash with key verbose. But Im not sure now, why is
this :verbose and not options["verbose"]?

Because the author chose to use Symbol over String for keys. This is
often done when the number of keys is known and limited.

The introductory material out there (hint, hint ) can probably
explain this a lot better and more exhaustively.

Cheers

robert

 

[Daniel Schoch]

ListElem = Struct.new rev, :next, :data
l1 = ListElem.new
li.data = "foo"
l2 = ListElem.new
l2.prev = l1
l1.next = l2
l2.data = "bar"
p l1

Ok, that works and solved my problem. Thanks.

I also found this comment in one of the ruby getting started texts.

Ruby variables hold references to objects and the = operator copies
references.

Now what about this ?
b = 1
a = b
b = 2
Shouldn't 'a' now contain 2 if the above statement is true? Clearly not
every variable is a reference.

 

[Robert Klemme]

Ok, that works and solved my problem. Thanks.

I also found this comment in one of the ruby getting started texts.

Now what about this ?
b = 1
a = b
b = 2
Shouldn't 'a' now contain 2 if the above statement is true? Clearly not
every variable is a reference.

Please think again. It's the same logic as above.

Cheers

robert

 

[Yossef Mendelssohn]

I also found this comment in one of the ruby getting started texts.


Now what about this ?
b =3D 1
a =3D b
b =3D 2
Shouldn't 'a' now contain 2 if the above statement is true? Clearly not
every variable is a reference.

This isn't entirely the same with numbers as with many other Ruby data
types because Fixnum is immediate. (There's only one instance of 1.)

But to show the same example using a different datatype:

b =3D 'hi' # b is now a reference to a variable containing the string
'hi'
a =3D b # a and b now reference the same variable. Changing one
(using sub! or similar) will change both
b =3D 'hello' # b is now a reference to a different variable containing
the string 'hello', a is still the old reference to 'hi'

 

[Robert Klemme]

This isn't entirely the same with numbers as with many other Ruby data
types because Fixnum is immediate. (There's only one instance of 1.)

This is irrelevant from a user's point of view. The logic stays the same:

b = 1 # or any other object!
a = b # a now points to the same object, 1 in this case
b = 2 # or any other object! a still points to 1 while b points to 2

Even though it's technical different under the hood - Fixnums blend
totally with other objects with regard to reference handling.

But to show the same example using a different datatype:

b = 'hi' # b is now a reference to a variable containing the string
'hi'
a = b # a and b now reference the same variable. Changing one
(using sub! or similar) will change both
b = 'hello' # b is now a reference to a different variable containing
the string 'hello', a is still the old reference to 'hi'

As you demonstrated - it's all the same.

Cheers

robert

 

[Yossef Mendelssohn]

This is irrelevant from a user's point of view. =A0The logic stays the sa= me:

b =3D 1 # or any other object!
a =3D b # a now points to the same object, 1 in this case
b =3D 2 # or any other object! a still points to 1 while b points to 2

I only pointed it out because there's no way (that I know of) to show
that a and b point to the same object at one point if a Fixnum is
used. You can use 'hi'.sub!, but there's no 1.succ!

 

[Robert Klemme]

I only pointed it out because there's no way (that I know of) to show
that a and b point to the same object at one point if a Fixnum is
used. You can use 'hi'.sub!, but there's no 1.succ!

You can use #object_id for that - even for Fixnums.

Cheers

robert

 

[Daniel Schoch]

Please think again. It's the same logic as above.

well, well. That's one hell of an explantion. But I guess it works out
ok. It's a bit of a getting used to if one is used to C in daily life.

 

[Brian Candler]

I just started with ruby and I understand from reading the documentation
that pointers don't exist. I'm in the process of writing a netlister.
Such a software is usually built using several linked lists. More
precisely, each element of one list contains a pointer to an element of
some other list.
So I was wondering how this can be achieved.

In Ruby everything is a reference to an object, and you can think of a
reference as a pointer to that object's representation in memory.

There is an optimisation for Fixnum, nil, false and true which means
that these don't actually allocate memory, because the value is buried
within the reference itself, but from the outside they still behave the
same:

a = 3
puts a # 3

class Fixnum
def double
self + self
end
end

puts a.double # 6

Note that Fixnum/true/false/nil are immutable. That is, you can't change
the value of the object '3', but you can change your variable so that it
holds a reference to some other object.

a = 4 # a now points to a different Fixnum
puts a # 4

For mutable objects, you end up with aliasing effects:

a = "hello"
b = a # pointer to same object
a.upcase!
puts a # "HELLO"
puts b # "HELLO"

The aliasing is the same as you'd get with

char *a = strdup("hello");
char *b = a;

HTH,

Brian.

 

[Rick DeNatale]

[Note: parts of this message were removed to make it a legal post.]

well, well. That's one hell of an explantion. But I guess it works out
ok. It's a bit of a getting used to if one is used to C in daily life.

This might help
http://talklikeaduck.denhaven2.com/articles/2006/09/13/on-variables-values-and-objects

at least it shouldn't hurt.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

 

[Daniel Schoch]

This might help

http://talklikeaduck.denhaven2.com/articles/2006/09/13/on-variables-values-and-objects

Yes, thank you. That's a good explanation. I think I got the hang of it
now and I'm making good progress.

 

[David Masover]

I only pointed it out because there's no way (that I know of) to show
that a and b point to the same object at one point if a Fixnum is
used. You can use 'hi'.sub!, but there's no 1.succ!

However, Fixnums can have instance variables, just like any other number.

class Fixnum
attr_accessor :foo
end

5.foo = :bar
4.foo # nil
6.foo # nil
5.foo # :bar

 

[Rick DeNatale]

[Note: parts of this message were removed to make it a legal post.]

As Robert Klemme pointed out, you can tell whether two variables reference
the same object using object_id

Two references a, and b refer to the same object iff a.object_id ==
b.object_id.

This is true regardless of the class of the object(s) involved in the test.

Object#equal? should also work. Object#== checks object identity by
default, but is often overridden to implement a more 'value based' notion of
equality.
By convention classes are not supposed to override Object#equal?

However, Fixnums can have instance variables, just like any other number.

class Fixnum
attr_accessor :foo
end

5.foo = :bar
4.foo # nil
6.foo # nil
5.foo # :bar

Yes, but I'm not sure what that has to do with determining whether a fixnum

is identical to another object.

By the way, instance variables for immediate objects like fixnums are
implemented differently than instance variables of objects which take up
memory.

For non-immediate objects, the instance data has a pointer to a hash table
which maps the iv name to a value (in Ruby < 1.9) or to shared hash table
which maps the iv name to an index.

For immediate objects, there's a global hash which maps the object_id of the
object to a hash containing that instance's instance variable names and
values.

One thing that immediate objects CAN'T have is a singleton class and
therefore singleton methods.

irb(main):001:0> a = "a String"
=> "a String"
irb(main):002:0> def a.foo;"foo";end
=> nil
irb(main):003:0> a.foo
=> "foo"
irb(main):004:0> a = 1
=> 1
irb(main):005:0> def a.foo;"bah";end
TypeError: can't define singleton method "foo" for Fixnum
from (irb):5

This is because immediate objects don't have a place for the klass pointer
which points to the first module, or module like object searched for
methods, so there's no place to insert a singleton class at the head of the
chain for immediate objects. In the case of immediate objects, the Ruby VM
knows from the bit encoding of the value that it's a FixNum, or nil, or true
..., and starts the search with the particular class.


--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

 

[Yossef Mendelssohn]

You can use #object_id for that - even for Fixnums.

Good point, though I still stick to my guns and say that showing this
with a different object, like a String, is clearer. Seeing that two
numbers have the same object_id doesn't carry the same weight as
seeing that mutating the value of variable (as in a =3D 'hi'; a.upcase!)
will change the value of another.

Maybe I look at it something like trying to write a failing test
before writing some code. Sure you can show that

a =3D 3
b =3D a
a.object_id =3D=3D b.object_id # true

But that's not very interesting because 3.object_id =3D=3D 3.object_id.
It's different with strings

'hi'.object_id =3D=3D 'hi'.object_id # false
a =3D 'hi'
b =3D a
a.object_id =3D=3D b.object_id # true

 

[lasitha]

One thing that immediate objects CAN'T have is a singleton class and
therefore singleton methods.

Ah, good to know! Thanks Rick.
lasitha.