Re: returning references
On Jan 4, 6:48 am, Christopher <cp...@austin.rr.com> wrote:
On Jan 3, 11:14 pm, "Daniel T." <danie...@earthlink.net> wrote:
pauldepst...@att.net wrote:
Below is posted from a link for Stanford students in computer
science.
QUOTE BEGINS HERE
Because of the risk of misuse, some experts recommend never
returning a reference from a function or method.
QUOTE ENDS HERE
I have never heard anyone else say that it is a problem for a
function to return a reference.
"C++ Coding Standards" by Sutter & Alexandrescu. Item 42: Don't give
away your internals.
Don't volunteer too much: Avoid returning handles to internal data
managed by your class, so clients won't uncontrollably modify
state that your object thinks it owns.
For context, "handles" above is defined as non-const references, and
pointers to non-const data.
So now you have heard of at least two acknowledged experts who almost
state the same thing.
I beg to differ with the statement that two quotes from so called
experts _almost_ say the same thing. They are extremely different
considering the impact of const correctness. the former quote is
moronic and the latter is imo quite correct.
The real difference is that they are addressing two radically
different levels. The Sutter/Alexandrescu quote has nothing to
do with references per se, but is more concerned with design;
I'm sure that neither Sutter nor Alexandrescu would condemn
std::vector<>::operator[] because it returns a reference (to
internal data, no less), nor the operator<< and operator>> in
iostream because they return a reference to support chaining.
(Alexandrescu definitly doesn't like iostream, but I don't think
that the fact that operator<< returns a reference has anything
to do with it.)
The real difference is that Sutter and Alexandrescu address a
real issue with their comment: how to intelligently design a
class. Where as the quoted recommendation simply misses the
point entirely, by concentrating on an irrelevant syntax issue.
(How is returning a reference riskier than returning a pointer,
for example?)
Are there really experts who object, or is this nothing
other than the commonplace observation that reference-
returning is a somewhat difficult concept that needs to be
learned carefully? (I am just learning about this now.)
Assuming programmers have some degree of competence and
are able to avoid returning references to locals and so
on, what (if anything) are the pitfalls?
The only valid reference that can be returned from a
non-member function is something that either the calling
code had access to anyway, or something that is buried in a
module.
The only valid reference that can be returned from a
member-function is of something that either the calling code
had access to anyway, or something that is private within
the class.
What's stopping me from returning a reference to protected
data exactly?
In either case, if you are returning a non-const reference,
then the object returned better not have anything to do with
the invariant of that class/module or the class/module is
asking for trouble (encapsulation is broken.)
agreed.
But what does that say, anyway? And how is returning a
reference any more of a problem here than returning a pointer.
There are two issues with returning a reference; permitting
access to internal details, and the lifetime of what is referred
to. They're both design issues, both affect other constructs as
well, and neither affects all use of references. Many standard
idioms and patterns involve returning references, and I've never
heard of any expert who recommended never returning a reference.
--
James Kanze (GABI Software) mailto:james.kanze@gmail.com
Conseils en informatique orient=EF=BF=BDe objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=EF=BF=BDmard, 78210 St.-Cyr-l'=EF=BF=BDcole, France, +33 (0)1 30 2=
3 00 34