Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > returning references

Reply
Thread Tools

returning references

 
 
pauldepstein@att.net
Guest
Posts: n/a
 
      01-04-2008
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. 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?

Paul Epstein
 
Reply With Quote
 
 
 
 
Christopher
Guest
Posts: n/a
 
      01-04-2008
On Jan 3, 6:26 pm, (E-Mail Removed) 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. 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?
>
> Paul Epstein


I don't see anything at all with returning references as long as the
const keyword is used correctly when appropriate. Surprisingly, a good
number of people do not use const when creating thier function stubs;

const MyClass & GetMyClass() const; // The typical accessor
SetMyClass(const MyClass & myclass); // The typical mutator

I constantly find the above two methods lacking the const keyword in
source when I am debugging and it leads to misuse by other programmers
who simply glance at a method without taking into account the impact
of making changes to the returned reference.

Another common problem I run into is you can't return NULL for a
reference. Sometimes it is nice to have the option to return NULL when
an error occured in which case I use a pointer and tell the caller to
check the returned value to determine if an error occured. Some people
don't like that idea though, but it is worth mentioning.
 
Reply With Quote
 
 
 
 
Erik Wikström
Guest
Posts: n/a
 
      01-04-2008
On 2008-01-04 01:26, http://www.velocityreviews.com/forums/(E-Mail Removed) 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. 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?


As far as I know there is only one pitfall, and that is returning a
reference to a variable local to the function, like so:

int& foo(int i)
{
int r = i+i;
return r;
}

int main()
{
int& twice = foo(5);
}

Since r is a local variable to foo() it will go out of scope as soon as
foo() is done executing, this means that the reference returned refers
to a variable that no longer exists.

On the other hand there are a number of valid reasons to return a
reference from a function, a function that returns an element from a
collection is a good example (look at the at() function in std::vector).

--
Erik Wikström
 
Reply With Quote
 
kwikius
Guest
Posts: n/a
 
      01-04-2008
On Jan 4, 12:26*am, (E-Mail Removed) 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


hmmm... I assume that following this extremely wise and useful advice,
Stanford students will not be allowed to do ...

#include <iostream>
int main(){
std::cout << "hello world\n";
}


regards
Andy Little

(Thankfully Not a C++ expert!)
 
Reply With Quote
 
Daniel T.
Guest
Posts: n/a
 
      01-04-2008
(E-Mail Removed) 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.

> 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.

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.)
 
Reply With Quote
 
Christopher
Guest
Posts: n/a
 
      01-04-2008
On Jan 3, 11:14 pm, "Daniel T." <(E-Mail Removed)> wrote:
> (E-Mail Removed) 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.


> > 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.
 
Reply With Quote
 
Salt_Peter
Guest
Posts: n/a
 
      01-04-2008
On Jan 3, 7:26 pm, (E-Mail Removed) 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. 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?
>
> Paul Epstein


Nothing wrong in returning references, example: various operators.
You already coverred the case of returning a temporary.
One pitfall is side-effects where an accessor might _get_ nasty.
Thats where CV-qualifiers play an important role.

#include <iostream>
#include <ostream>

class N
{
int m_n;
public:
N(int n) : m_n(n) { }
// accessors
int& getnasty() { return m_n; } // nasty
int const& getsafe() const { return m_n; }
void set(const int& n) { m_n = n; }
// friend op<<
friend std:stream&
operator<<(std:stream& os, const N& r)
{
return os << r.m_n;
}
};

int main()
{
N instance(9);
std::cout << instance << std::endl;

instance.getnasty() = -1; // nasty side-effect
std::cout << instance << std::endl;

instance.set(;
std::cout << instance << std::endl;
std::cout << instance.getsafe() << std::endl;
}

/*
9
-1
8
8
*/
 
Reply With Quote
 
Barry
Guest
Posts: n/a
 
      01-04-2008
kwikius wrote:
> On Jan 4, 12:26 am, (E-Mail Removed) 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

>
> hmmm... I assume that following this extremely wise and useful advice,
> Stanford students will not be allowed to do ...
>
> #include <iostream>
> int main(){
> std::cout << "hello world\n";


well this is allowed, while
std::cout << "hello world" << std::endl;
is not,

write
std::cout << "hello world";
std::cout << std::endl;
instead.



> }
>
>
> regards
> Andy Little
>
> (Thankfully Not a C++ expert!)

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      01-04-2008
On Jan 4, 6:48 am, Christopher <(E-Mail Removed)> wrote:
> On Jan 3, 11:14 pm, "Daniel T." <(E-Mail Removed)> wrote:
> > (E-Mail Removed) 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<>:perator[] 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) (E-Mail Removed)
Conseils en informatique orient�e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
Erik Wikström
Guest
Posts: n/a
 
      01-04-2008
On 2008-01-04 10:29, Barry wrote:
> kwikius wrote:
>> On Jan 4, 12:26 am, (E-Mail Removed) 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

>>
>> hmmm... I assume that following this extremely wise and useful advice,
>> Stanford students will not be allowed to do ...
>>
>> #include <iostream>
>> int main(){
>> std::cout << "hello world\n";

>
> well this is allowed, while
> std::cout << "hello world" << std::endl;
> is not,
>
> write
> std::cout << "hello world";
> std::cout << std::endl;
> instead.


The reference will be returned regardless if you use it or not, but I
guess they make an exception for library functions

PS. Please do not quote signatures

--
Erik Wikström
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Snake references just as ok as Monty Python jokes/references in python community? :) seberino@spawar.navy.mil Python 8 12-12-2006 11:21 PM
Typedef A references struct B which references struct A which... DanielEKFA C++ 8 05-16-2005 10:26 AM
Difference between bin and obj directories and difference between project references and dll references jakk ASP .Net 4 03-22-2005 09:23 PM
how to understand references to variables and references to constants are distinguished? baumann.Pan@gmail.com C++ 3 11-10-2004 04:16 AM
Pointers and References (and References to Pointers) Roger Leigh C++ 8 11-17-2003 10:14 AM



Advertisments