Forum: Ruby pointer and other questions

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Bf3dca60b50251a5fee8fcab8198560d?d=identicon&s=25 Daniel Schoch (dsul)
on 2009-02-23 21:01
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.
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-02-23 21:15
(Received via mailing list)
On 23.02.2009 21:00, Daniel Schoch 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).

> 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
Bf3dca60b50251a5fee8fcab8198560d?d=identicon&s=25 Daniel Schoch (dsul)
on 2009-02-23 21:41
>
> 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.
B1b1d33e0655e841d4fd8467359c58d0?d=identicon&s=25 Yossef Mendelssohn (Guest)
on 2009-02-23 22:10
(Received via mailing list)
On Feb 23, 2:40 pm, Daniel Schoch <tr...@tekwissusa.com> 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'
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-02-23 22:11
(Received via mailing list)
On 23.02.2009 21:40, Daniel Schoch 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
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-02-23 22:25
(Received via mailing list)
On 23.02.2009 22:09, Yossef Mendelssohn 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
B1b1d33e0655e841d4fd8467359c58d0?d=identicon&s=25 Yossef Mendelssohn (Guest)
on 2009-02-23 22:44
(Received via mailing list)
On Feb 23, 3:24 pm, Robert Klemme <shortcut...@googlemail.com> 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!
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-02-23 23:00
(Received via mailing list)
On 23.02.2009 22:42, Yossef Mendelssohn wrote:
> On Feb 23, 3:24 pm, Robert Klemme <shortcut...@googlemail.com> 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. :-)

Cheers

  robert
Bf3dca60b50251a5fee8fcab8198560d?d=identicon&s=25 Daniel Schoch (dsul)
on 2009-02-23 23:02
>
> 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.
753dcb78b3a3651127665da4bed3c782?d=identicon&s=25 Brian Candler (candlerb)
on 2009-02-24 10:58
Daniel Schoch 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.
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-24 14:57
(Received via mailing list)
On Mon, Feb 23, 2009 at 5:01 PM, Daniel Schoch <trash@tekwissusa.com>
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/0...

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
Bf3dca60b50251a5fee8fcab8198560d?d=identicon&s=25 Daniel Schoch (dsul)
on 2009-02-24 15:36
> This might help
> http://talklikeaduck.denhaven2.com/articles/2006/0...

Yes, thank you. That's a good explanation. I think I got the hang of it
now and I'm making good progress.
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-24 22:13
(Received via mailing list)
Yossef Mendelssohn 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
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-24 23:41
(Received via mailing list)
On Tue, Feb 24, 2009 at 4:12 PM, David Masover <ninja@slaphack.com>
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 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.
> 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
B1b1d33e0655e841d4fd8467359c58d0?d=identicon&s=25 Yossef Mendelssohn (Guest)
on 2009-02-25 00:10
(Received via mailing list)
On Feb 23, 3:59 pm, Robert Klemme <shortcut...@googlemail.com> wrote:
> On 23.02.2009 22:42, Yossef Mendelssohn 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. :-)

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
E16e84e861c1815ce11ba7bd851c857d?d=identicon&s=25 lasitha (Guest)
on 2009-02-25 05:01
(Received via mailing list)
On Wed, Feb 25, 2009 at 4:09 AM, Rick DeNatale <rick.denatale@gmail.com>
wrote:
> One thing that immediate objects CAN'T have is a singleton class and
> therefore singleton methods.

Ah, good to know!  Thanks Rick.
lasitha.
This topic is locked and can not be replied to.