I think part of your confusion here, SFAM, is that you're talking about
"pointers" and "references" as if they were distinct entities. They are
not. A pointer is a kind of reference; an implementation detail, in
effect. So C, you see, has references (as do various assemblers, in the
same general form). They are called "pointers" and have some ugly
syntax and semantics:
int a = 5; /* a is a box holding 5 */
int *b = &a; /* b is a box that points to 5 */
int c = a; /* c is a box holding 5 */
int d = *b; /* d is a box holding 5 */
a = 6; /* a now holds 6, b points to 6, c & d are boxes
holding 5 */
Note how ugly the reference syntax is in C? You have to explicitly tell
it that it is a reference (int *b) and you have to use special syntax to
turn a variable into a reference (&a). Later, when you want to use the
value of the referent, you need, again, to explicitly say so (*b).
(Now, to be fair, there are some pretty cool tricks you can do with C's
references, but we're in the realm of using chainsaws to clip our
fingernails when we use a feature with that much power to do routine
application things.)
References in C++ are either the old-style C references (pointers) or a
newer breed of reference which they confusingly call... references. As
if they were something different. Now the syntax is a bit friendlier:
int a = 5; // a is a box holding the value 5
int &b = a; // b is a box holding the location of the box a
int c = a; // c is a box holding the value 5
int d = b; // d is a box holding the value 5
a = 6; // a now holds 6, b points to 6, c and d & boxes
holding 5
Note that you still have to specifically say that a variable is a
reference (int &b), but you no longer have to take addresses explicitly
(no &a) and you no longer have to tell the compiler that you mean the
value pointed to, not its location (no *b). Under the covers, though,
it's all the same thing: boxes with values and other boxes that point to
those values. There's only a few minor advantages to using references
over pointers:
1. The cleaner syntax. (You can't make the mistake of accidentally
using an address when you mean the value.)
2. The lower power. (Yes, this is an advantage: you're clipping
your nails with a belt sander instead of a chainsaw. :D)
3. The compiler can better reason about the data involved and can
silently optimize away the actual references if it turns out
that using the data straight is safer and won't have any
semantic impact.
Ruby's references are a completely different implementation. And,
indeed, Ruby's variables in general are radically different in nature.
A variable in Ruby is more like a file handle (another form of
reference, incidentally) or an array index (yet another form of
reference) than it is like a C or C++ variable (a box with a value).
a = 5 # a.object_id is 11 in my irb session.
b = a # a and b.object_id are both 11.
c = a # a, b and c.object_id are all 11.
d = b # a, b, c and d.object_id are all 11.
a = 6 # a.object_id is now 13. b, c and d.object_id are all
still 11.
Note that here things are radically different from C/C++ (whose
"pointers" and "references" are basically the same thing under the
covers and implemented in mostly the same way). a is not a box with a
value. a is an abstract label (value 11) that is used by the Ruby
runtime to find the value 5. You can view it as a "pointer" of sorts,
but it's probably better to think of it like you'd think of a file
handle returned from an fopen() system call: it's an opaque data
structure containing a lot of information behind the scenes, one of
which happens to be an indirect reference to the value 5. When we
assign a to b, b is now the very same thing. It's just another name, in
effect, for exactly the same object information (which happens to
indirectly reference the value 5). As we proceed to c (from a) and d
(from b), we're basically just attaching more names to the very same
information. It's sort of like doing fopen() several times on the same
file (as long as you ignore issues like seeking, etc.). At the very
end, when I assign 6 to a, what I'm really doing is making a brand new
"handle" that contains, among other things, an indirect reference to the
value 6. This does not change, in any way, the values assigned to b, c
or d. Those are still handles to the same data structure with its
indirect reference to 5.
So....
Short version: Ruby variables are all references. So are C++
"references" and C/C++ "pointers". But the Ruby implementation is
radically different from the C/C++ versions. The sooner you leave your
C/C++-derived notions of what variables "really" are and how they
"really" work behind, the sooner you will understand the subtler aspects
of Ruby's semantics.
If you're still having troubles figuring this out (or if anybody else is
quietly watching this and still getting confused), drop me a line by
private email and I'll hack together some C++ code that kinda-sorta does
the same thing as Ruby so you can understand what's going on in a
variable structure you're more familiar with.
···
On Sun, 2007-30-09 at 15:39 +0900, SpringFlowers AutumnMoon wrote:
how about just a.set_value(3) vs a->set_value(3). what i mean is just
the "." and "->" difference. using a "." in Ruby and "->" in C or C++.
If I think of "a" as a pointer and "." as "->", will that get in trouble
and have any discrepancy for other things.
--
Michael T. Richter <ttmrichter@gmail.com> (GoogleTalk:
ttmrichter@gmail.com)
We should sell bloat credits, the way the government sells pollution
credits. Everybody's assigned a certain amount of bloat, and if they go
over, they have to purchase bloat credits from some other group that's
been more careful. (Bent Hagemark)
