> In developing some coding standards at my job a discussion
> came up over the relative merits of pointers versus references.
> A coworker has suggested we shun references and explicitly
> use pointers, the idea being that it's easier to know in
> the midst of a routine that changing a field of a pointer
> parameter will change it elsewhere, while a reference
> looks like a locally-scoped object or class memeber.
There are two major points of view to this problem found in the
1. Use a pointer instead of a non-const reference because it makes more
clear that you modify an external variable or that variable can be
modified in the function.
2. Use a reference wherever possible as it makes calling syntax and the
big picture of a function cleaner.
As it concerns the first point, even if pointers may signal to a
programmer that a variable can change it does not say it will. You can
always pass a pointer to a variable that is not going to change with the
calling syntax remaining the same. In the case of any incertitude
examining the called function signature and its pre/post conditions will
Information inside the function implementation whever you modify an
external variable is usually less important and even if, should be
rather based on function pre/post conditions as they are more complete.
There are also situations when calling a function you do not care, if
the variable is going to change or not, just because it is of an
abstract type provided by some external library, or you may wish to
obtain some syntax convenience.
I suppose that most of us got caught once in the past with the C scanf
function syntax while expecting that it could be analogical to more
often used printf. It was indeed, almost... Using a reference to the
passed variable could remove that problem completely.
And such attitude refers the second point focusing on making the
function calling syntax more simple and clean hence readable and easier
to use. You do not have to keep in mind that a function needs the
address of a variable, remembering that a function requires a variable
of given type is much easier.
It remains up to the called function to be more "clever" than the code
that calls it and to use the given parameters properly.
It all appears as a tradoff to resolve - more information vs more
abstraction. I think that the second attitude is closer to OO and should
be prefered at least when it concerns definition of external interfaces.
Quote:> Can anyone speak up for the reference and make a good
> case for using it instead of a pointer?
It should be kept in mind that pointers and references are physically
very different. Pointers are legal variables while references only
aliases for other ones. When passing a parameter to a function,
references should be at least theoretically faster (no pointer
dereferencing is needed) and were conceived to deal more cleanly with
such situations where using a pointer can be considered as a workaround
for the same goal.
There are of course such situations when physically existing pointers
are really needed, but in many cases references may be a better
Quote:> One notion that's occured to me is that, if one is to use
> pointers, passing references to pointers instead of simple
> pointers is actually safer. If the object is deleted and
> the pointer-reference is set to NULL, it will be NULL everywhere.
But if assuming that every pointer will point everytime to the same
variable. It is quite a strong assumption to be a general rule. It is
also quite difficult to be obtained in large projects. Syntax mess
introduced that way may not be worth the results. I believe that more
traditional defining systematically function responsibility for deleting
an object should be more successful.