* Ioannis Vranos:
I do not find that FAQ particularly useful. More accurately I believe it
is full of (nicely termed) nonsense.
Do you consider it useful?
The FAQ explained:
<q>Use references when you can, and pointers when you have to.</q>
Explanation: if you can use a reference, use a reference.
Otherwise, use a pointer.
This is good advice because references are more limited than pointers, so to
screw up you have to work much harder at it when all you have is a reference.
<q>References are usually preferred over pointers whenever you don't need
"reseating"</q>
Explanation: if you don't need to let the same variable refer to different
objects at different times, you can probably use a reference, and so you
should probably use a reference.
<q>This usually means that references are most useful in a class's public
interface.</q>
Explanation: the public interface of a class let's you pass information into
and get information out of an object. Unless there is a need for a logical
null-value this can be done using references. Hence use references here.
<q>References typically appear on the skin of an object, and pointers on the
inside.</q>
Explanation: in the code that implements an object pointers may be needed
because there one may need to let the same variable refer to different objects
at different times, or handle logical null-values. For example, in a linked
list class you need pointers inside. But the interface can be and probably
should be expressed with references only, giving the client code existence
guarantees that greatly simplifies the client code.
<q>The exception to the above is where a function's parameter or return value
needs a "sentinel" reference.</q>
Explanation: this is the logical null-value referred to above.
<q>This is usually best done by returning/taking a pointer, and giving the
NULL pointer this special significance (references should always alias
objects, not a dereferenced NULL pointer).</q>
Explanation: here Marshall Cline is expressing an opinion, which e.g. Bertrand
Meyer (the Eiffel man) seems to be diametrically opposed on. I'm personally
somewhere in between, choosing whatever seems most practical. But I think I
mostly lean in the direction Marshall is pointing here: it's too cumbersome to
have isVoid() functions, especially since a functional interface isn't
something that usually can be passed further around as data, as a pointer can.
<q>Note: Old line C programmers sometimes don't like references since they
provide reference semantics that isn't explicit in the caller's code.</q>
Explanation: people often do things out of habit and then rationalize it by
inventing reasons. Flame wars have therefore been fought over whether an "&"
in the client code indicates -- or not -- that an actual argument is an
out or an in/out (as opposed to pure in) argument. The facts are (1) that "&"
in the client code tells you nothing, (2) that in the C language the lack of
"&" tells you that argument is pure in, and (3) that in C++ the lack of "&"
doesn't tell you anything, either: you need to know about the function called.
<q>After some C++ experience, however, one quickly realizes this is a form of
information hiding, which is an asset rather than a liability.</q>
Explanation: this is not a technical comment but a methodological one. I
happen to agree with Marshall here but it's not universally agreed on. Anyway
the only connection to C++ is that the "&"-issue is a concrete example.
<q>E.g., programmers should write code in the language of the problem rather
than the language of the machine.</q>
Explanation: same as the previous one.
