Not worrying about anything and not worrying about references about the
inner workings of references are two different things. I am positive that
this professor is pushing the students to worry a lot about many things.
You can worry all you want about the inner workings of references, it won't
do you any good because the standard does not specify those. The standard
does not say what references are nor how they work "under the covers".
Thus, you have no means to address you worries. In that sense, the
professor is just stating a truism. The only programmers who have a
meaningful opportunity to worry about how references work "under the
covers" are those programmers that implement C++ compilers.
Not true. We are working with actual compilers. What about those
programmers that need to step code and look at the disassembly to see
where optimizations can occur (not just compiler writers). My point
was that someone who knows how the inner parts work in practice will
be better able to make decisions than those who don't. And, do you
really think, that a person who has been indoctrinated in the 'new C+
+' idea of 'aliases' is never going to encounter an old C-style
programmer on the job. There's no point in hiding this stuff from
them-- if they're any good at all, they're gonna figure it out
completely eventually anyway. If a total novice wants to think of
references as aliases, that's fine, but there's no way you're gonna
convince me that's what they are because I know better. Alias adds
nothing to 'reference'--both are abstract concepts which in practice
turn out to be hidden ptrs.
All other programmers should be busy enough worrying about the life-time of
objects bound to references and the provisions for initializing references..
None of those are intuitive and none of those are successfully captured in
any of the nutshell-explanations for references. I find that neither the
talk about aliases nor the comparison with pointers is helpful in dealing
with references. There is nothing more (but also nothing less!) to
references than the specs from the standard; and those rules are
complicated and cannot be captured by a simple slogan or comparison.
As I said, anytime you start stepping code (especially if you step
into the disassembly) you're going to become familiar with these
things. And, to be honest, for me, it is just simpler to reason about
the reference as what it actually is in practice (and that was in fact
the way I was taught by my professors, who were no doubt well-versed
in C and assembly to begin with). If anyone here can come up with an
alternate implementation of a reference that isn't a pointer, I would
love to see it, but until such a compiler comes out, what harm does it
do to think of them as such? In fact, I actually think of
'references' as 'entities that *refer* to other entities. The whole
'alias' vs 'pointer' debate is merely a difference of nomenclature and
quite superficial.
As I've said before though, I understand that the standard doesn't
require that refs be ptrs, but as anyone coming from assembly or C to C
++, they're gonna immediately recognize them as such and until such
time as the 'theoretical' alternate implementation of a ref that isn't
a ptr comes out, I see no harm in thinking of them as such. And, I
would add, when this 'fantastic' uber-reference comes out, I will have
a compiler and a debugger at that time and will be able to step right
in to it as well and understand exactly what it is (if needed).
Let me ask you this: would you prefer a mechanic that doesn't know
the internals of an electric starter, but can simply determine when
the starter is bad and replace it -or- the one who can break apart the
starter and service the brushes and armature (assuming that its
economical to do so).
If they want students to not worry about
stuff, then they should just become a 'Java school' (though I disagree
with Java programmers not worrying about stuff too).
[snip]
This is converging toward drivel and language wars. It does not add anything
meaningful to the technical discussion of references in C++.
Well, given as how this is a C++ group, I thought you guys might like
the complement (seeing as how some of my other posts seem to have
derided it). But, to be clear, I like to approach each language
objectively and praise those parts which are good and critique those
parts which could use work. I don't know if you read Joel's page or
not, but it is quite insightful (and I figured that the C++ group
would see that point and be able to extrapolate it to the practice of
hiding details of references by calling them aliases). That might
work for ppl who have never seen C or assembly, but what is the real
advantage? If students can't understand ptrs (as Joel said), I think
they're in the wrong major.
I totally take the point that you can't depend on implementation
details, but I see absolutely no reason to indoctrinate people with
yet another imperfect metaphor for something that is quite simple. A
reference is something that 'refers' to something else. That much can
be gathered from the name itself. Alias adds absolutely nothing to
'reference'. If alias was a better word for this, then I think Bjarne
would have chosen it. But, given as how he chose reference, and C++
is an extension of C, it isn't a big leap to think that he was adding
a nice little tight syntax for passing something by reference which C
programmers were very accustomed to already.
Alias means 'another name for something else'. Reference means
'something that refers to something else'. Pointer means 'something
that points to something else', or if you get really technical about
it, a memory slot that contains the address of something else (which
in practice, references are too). To me, if something refers to
something else, it might as well 'point' to it. These are all
ontologically equivalent (i.e., conceptually) and technically in
practice, equivalent (at the assembly code level) at least with the
state of the art compilers.
Since C++ descended from C, you cannot simply look at it in
isolation. You have to look at the parts of C that 'inspired' the
features of C++ (and all of the C features that still remain, as C++
is essentially a superset of C (and yes, if you want to pick at minor
details, the two languages have slightly diverged of late)).
--Jonathan
