Re: C++ programmer and assembly
Francis Glassborow wrote:
Le Chaud Lapin wrote:
On Apr 14, 10:53 am, "jimmy b" <jimmy.can...@gmail.com> wrote:
i'm curious, could you explain this a bit. What understanding about
references would a programmer knowing assembly have (other than the
one you've mentioned - "they're implemented as pointers")?
The difference in understanding is very subtle and mostly conceptual.
The assembly programmer not only understands the mechanics, but the
"mood of mind" that the programmer should have while working with
references. The no-assembly programmer who does not understand
references will often not be aware of exactly what it is he does not
understand. To see this, here are some of the questions that a no-
assembler programmer who has been told that "pointers are just
references" programmer might ask:
1. How much spaces do references take up on 32-bit machine?
2. Why can I not assign a reference?
3. I want to have a map<const &Foo, void *>...but compiler won't let
me insert references. Why?
4. Why is it necessary to initialize a reference found in a base or
member of object at constructor time for that object, but not a
pointer?
5. Why can I not initialize a reference to null?
And every one of those is specific to the meaning of reference in C++.
Of course you can initialize a reference to null we just do not allow it
in C++. Of course you can assign to a reference it is just that in C++
this results in assigning to the referenced object.
It is just that C++ does not allow you to handle references as any form
of object so you cannot have a container of references in C++.
In all five of the above the important thing is understanding what a C++
reference is. It has nothing whatsoever to do with machine code. However
they are reasons why the naive description of references as just
syntactic sugar for pointers is unhelpful. Things are not their
implementation. The fact that references are usually implemented as
hidden pointers has _nothing_ to do with the semantics of a reference.
Indeed this is an excellent example of knowing low level details being a
handicap to understanding.
Ionno. To me, our favorite field is a scale-free space in which
knowledge at all levels simply allows you to better understand what's
going on at all other levels. In contrast, architecture and various
engineering disciplines rarely need to span the range from atom to large
structure. But I'm on a limb here.
Here's a contrived section of code I had in a talk I gave at ACCU:
T1 Widget::fun() {
...
T2 & temp = *p;
return &temp;
}
The temp variable was introduced to prevent ambiguities in a nontrivial
inheritance hierarchy. An astute attendee noticed that the code is
illegal because I'm returning the address of a temporary. Initially I
thought he's right, but after a second look, I figured that the code is
correct because temp is essentially an "always dereferenced" pointer, so
the code is equivalent to:
T1 Widget::fun() {
...
T2 * pTemp = p;
return &*pTemp;
}
I could have also inferred that the code is correct through other means,
but the simple understanding that references are pointers with a "*"
always stuck to them made it easy to figure things out.
Andrei
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]