--=-RpwYA6ZJWIRueyZpGlEz
Content-Type: multipart/related; type="multipart/alternative";
boundary="=-KNQF7uooAOCu7u7YrWkl"
--=-KNQF7uooAOCu7u7YrWkl
Content-Type: multipart/alternative; boundary="=-KIZHje2jedaXqVNnfiqj"
--=-KIZHje2jedaXqVNnfiqj
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
how about just a.set_value(3) vs a->set_value(3). what i mean is just=20
the "." and "->" difference. using a "." in Ruby and "->" in C or C++.=20
If I think of "a" as a pointer and "." as "->", will that get in trouble=20
and have any discrepancy for other things.
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 =3D 5; /* a is a box holding 5 */
int *b =3D &a; /* b is a box that points to 5 */
int c =3D a; /* c is a box holding 5 */
int d =3D *b; /* d is a box holding 5 */
a =3D 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 =3D 5; // a is a box holding the value 5
int &b =3D a; // b is a box holding the location of the box a
int c =3D a; // c is a box holding the value 5
int d =3D b; // d is a box holding the value 5
a =3D 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.
)
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 =3D 5 # a.object_id is 11 in my irb session.
b =3D a # a and b.object_id are both 11.
c =3D a # a, b and c.object_id are all 11.
d =3D b # a, b, c and d.object_id are all 11.
a =3D 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.
--=20
Michael T. Richter <
[email protected]> (GoogleTalk:
(e-mail address removed))
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)
--=-KIZHje2jedaXqVNnfiqj
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8">
<META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/3.12.1">
</HEAD>
<BODY>
On Sun, 2007-30-09 at 15:39 +0900, SpringFlowers AutumnMoon wrote:
<BLOCKQUOTE TYPE=3DCITE>
<PRE>
<FONT COLOR=3D"#000000">how about just a.set_value(3) vs a->set_value(3)=
what i mean is just </FONT>
<FONT COLOR=3D"#000000">the "." and "->" difference.=
using a "." in Ruby and "->" in C or C++. </FONT>
<FONT COLOR=3D"#000000">If I think of "a" as a pointer and "=
" as "->", will that get in trouble </FONT>
<FONT COLOR=3D"#000000">and have any discrepancy for other things.</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
I think part of your confusion here, SFAM, is that you're talking about &qu=
ot;pointers" and "references" as if they were distinct entit=
ies. They are not. A pointer is a kind of reference; an impleme=
ntation detail, in effect. So C, you see, has references (as do vario=
us assemblers, in the same general form). They are called "point=
ers" and have some ugly syntax and semantics:<BR>
<BR>
<BLOCKQUOTE>
<TT>int a =3D 5; /* a is a box holding 5 =
*/</TT><BR>
<TT>int *b =3D &a; /* b is a box that points to 5=
*/</TT><BR>
<TT>int c =3D a; /* c is a box holding 5 =
*/</TT><BR>
<TT>int d =3D *b; /* d is a box holding 5 */</T=
T><BR>
<TT>a =3D 6; /* a=
now holds 6, b points to 6, c & d are boxes holding 5 */</TT><BR>
</BLOCKQUOTE>
<BR>
Note how ugly the reference syntax is in C? You have to explicitly te=
ll 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 u=
se the value of the referent, you need, again, to explicitly say so (*b).&n=
bsp; (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 fingern=
ails when we use a feature with that much power to do routine application t=
hings.)<BR>
<BR>
References in C++ are either the old-style C references (pointers) or a new=
er breed of reference which they confusingly call... references. As i=
f they were something different. Now the syntax is a bit friendlier:<=
BR>
<BR>
<BLOCKQUOTE>
<TT>int a =3D 5; // a is a box holding the valu=
e 5</TT><BR>
<TT>int &b =3D a; // b is a box holding the locat=
ion of the box a</TT><BR>
<TT>int c =3D a; // c is a box holding the valu=
e 5</TT><BR>
<TT>int d =3D b; // d is a box holding the valu=
e 5</TT><BR>
<TT>a =3D 6; // a now h=
olds 6, b points to 6, c and d & boxes holding 5</TT><BR>
</BLOCKQUOTE>
<BR>
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 poi=
nted 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 valu=
es. There's only a few minor advantages to using references over poin=
ters:
<OL TYPE=3D1>
<LI TYPE=3D1 VALUE=3D1>The cleaner syntax. (You can't make the mi=
stake of accidentally using an address when you mean the value.)
<LI TYPE=3D1 VALUE=3D2>The lower power. (Yes, this is an advantag=
e: you're clipping your nails with a belt sander instead of a chainsaw. <IM=
G SRC=3D"cid:1191152265.32121.17.camel@isolde" ALIGN=3D"middle" ALT=3D"
" =
BORDER=3D"0">)
<LI TYPE=3D1 VALUE=3D3>The compiler can better reason about the data in=
volved 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.
</OL>
<BR>
Ruby's references are a completely different implementation. And, ind=
eed, Ruby's variables in general are radically different in nature. A=
variable in Ruby is more like a file handle (another form of reference, in=
cidentally) or an array index (yet another form of reference) than it is li=
ke a C or C++ variable (a box with a value).<BR>
<BR>
<BLOCKQUOTE>
<TT>a =3D 5 # a.object_id is 11 in my irb session.</T=
T><BR>
<TT>b =3D a # a and b.object_id are both 11.</TT><BR>
<TT>c =3D a # a, b and c.object_id are all 11.</TT><B=
R>
<TT>a =3D 6 # a.object_id is now 13. b, c and d=
object_id are all still 11.</TT><BR>
</BLOCKQUOTE>
<BR>
Note that here things are <B>radically</B> different from C/C++ (whose &quo=
t;pointers" and "references" are basically the same thing un=
der the covers and implemented in mostly the same way). a is not a bo=
x 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 o=
f a file handle returned from an fopen() system call: it's an opaque data s=
tructure containing a lot of information behind the scenes, one of which ha=
ppens to be an indirect reference to the value 5. When we assign a to=
b, b is now <B>the very same thing</B>. It's just another name, in e=
ffect, 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 <B>very same information</=
B>. It's sort of like doing fopen() several times on the same file (a=
s long as you ignore issues like seeking, etc.). At the very end, whe=
n I assign 6 to a, what I'm really doing is making a <B>brand new</B> "=
;handle" that contains, among other things, an indirect reference to t=
he 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 it=
s indirect reference to 5.<BR>
<BR>
So....<BR>
<BR>
Short version: Ruby variables are all references. So are C++ "re=
ferences" and C/C++ "pointers". But the Ruby implement=
ation is <B>radically</B> different from the C/C++ versions. The soon=
er you leave your C/C++-derived notions of what variables "really"=
; are and how they "really" work behind, the sooner you will unde=
rstand the subtler aspects of Ruby's semantics.<BR>
<BR>
If you're still having troubles figuring this out (or if anybody else is qu=
ietly 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 t=
hing as Ruby so you can understand what's going on in a variable structure =
you're more familiar with.<BR>
<BR>
<TABLE CELLSPACING=3D"0" CELLPADDING=3D"0" WIDTH=3D"100%">
<TR>
<TD>
-- <BR>
<B>Michael T. Richter</B> <<A HREF=3D"mailto:
[email protected]">ttmri=
(e-mail address removed)</A>> (<B>GoogleTalk:</B> (e-mail address removed))<BR>
<I>We should sell bloat credits, the way the government sells pollution cre=
dits. 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)</I>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>
--=-KIZHje2jedaXqVNnfiqj--
--=-KNQF7uooAOCu7u7YrWkl
Content-ID: <1191152265.32121.17.camel@isolde>
Content-Disposition: attachment; filename=smiley-1.png
Content-Type: image/png; name=smiley-1.png
Content-Transfer-Encoding: base64
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAC5UlEQVR42n2TW2hUZxSFv/8/Z6Jz
caKJwTGhyWi9glSUglYsRZFWECvYRir6ZL3jJRZLsYJQtAj6oC2IISBqQQg+SKOEKiRStUZ9EbyM
NcPEGSXRmMyJTjLnZOb8Z87fh6RCrbhgP+y1914va234P+qAHUAL4I7W78CW0dl/IN7qT86Kh7bu
2ziP5V/MxgzHoVTAHXpMR8df7P91gMfP3EZg27sE2n/aNnfpzl3fIIwgnp3BzScRwsAYOxmjrBJl
pzn2SxtHmrPtwDIAY/S46eCOj7/euXsdpeEelJPBVzmEDADguxaenQY0nyyIYzh9U28+LMSAVgHU
zZ05IXP1wh60N4Q33I0wgpR8iSF9dGkYt+hgYON7DmawmuLre3y++QnJ7lJcAitajlUgZADlPKXt
VpZNP14nvvg0ucCXHD3VybRll6j/LkE2tBuV78IMxthcPx5gkQAas/d/2KLspwDIQJRQzVo85aCd
RwgzTCAyC60scqkT+CqHNEPcudvFV3t7z5s1NdXfAvjeINKMgPYYfnEBIcvQvkKX8hT6r+F7NlAC
wCv0MXmiAbDatCyLP/58QiaVougFEDKAxkRKA7SP1mpEyC/iey4ClzLDZUJ0xECzUCi2tt/oXNWw
/zxKKSorKzFNk6qqqjf+aq3RWmNZFkopbNum9cwawLpjAlc+qn25KhbuQpZ/ipSS8vJytNZIKVFK
IYRACIGUEsdxKOYSdD7IADQbQH/mOQ0zYt18UJElk51IMpnEsiwAwuEwvb29pNNpEokEk6KvqBg8
zKGmbgby7DGAnJVTtTVRb96YQI45M8ZT/eESamvjRCIRpJQYxkjeqsblCfcf4PuDD7ie8BuB3/5N
4sXbDwc/i8r8FG/oBsJqJlhWwHPzDPSl6O+5z4vUZSapJn4+nuBsu7oG1L/rmU5NickNKxeG2Lt9
+hvyeZ/LlY7XnGvpIdnDOWA970Ed0ADcAhRgAX8DJ4D5by//A0f8RUIabvq3AAAAAElFTkSuQmCC
--=-KNQF7uooAOCu7u7YrWkl--
--=-RpwYA6ZJWIRueyZpGlEz
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
iD8DBQBG/48/LqyWkKVQ54QRAqdVAJ4o1fqEGesV/L83knIBCs7GWuJeZgCdGI3j
0a3tPvCQ+S2hl6uyGOGvu3U=
=ynOR
-----END PGP SIGNATURE-----
--=-RpwYA6ZJWIRueyZpGlEz--
