Pointer and other questions

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.

On 23.02.2009 21:00, Daniel S. wrote:

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 :prev, :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).

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

ListElem = Struct.new :prev, :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.

On Feb 23, 2:40 pm, Daniel S. [email protected] wrote:

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 = ‘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’

On 23.02.2009 21:40, Daniel S. wrote:

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.

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

Cheers

robert

On 23.02.2009 22:09, Yossef M. wrote:

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.)

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

On Feb 23, 3:24 pm, Robert K. [email protected] wrote:

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

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!

On 23.02.2009 22:42, Yossef M. wrote:

On Feb 23, 3:24 pm, Robert K. [email protected] wrote:

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

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. :slight_smile:

Cheers

robert

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.

Daniel S. wrote:

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.

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.

On Mon, Feb 23, 2009 at 5:01 PM, Daniel S. [email protected]
wrote:

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.

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

Yossef M. wrote:

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

On Feb 23, 3:59 pm, Robert K. [email protected] wrote:

On 23.02.2009 22:42, Yossef M. wrote:

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. :slight_smile:

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 = ‘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 = 3
b = a
a.object_id == b.object_id # true

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

‘hi’.object_id == ‘hi’.object_id # false
a = ‘hi’
b = a
a.object_id == b.object_id # true

On Tue, Feb 24, 2009 at 4:12 PM, David M. [email protected]
wrote:

b = 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!

As Robert K. 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.

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

On Wed, Feb 25, 2009 at 4:09 AM, Rick DeNatale [email protected]
wrote:

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

Ah, good to know! Thanks Rick.
lasitha.