returning a reference

S

Stefan Ram

bob smith said:
Can someone help me understand what really happens when a function returns a reference?

A reference - as far as I understand it - is not a run-time
value, but a certain kind of source code name or type.

When a name or type is tagged to be a reference, this
modifies the semantics of certain definitions and expressions.

So, it indeed modifies also the run-time behavior, but
this does not mean that references exist as run-time entites.
For instance, there is this function:
http://www.cplusplus.com/reference/vector/vector/operator[]/
Is it really returning a pointer?

It might be a help to rewrite code that uses references to
code using pointers as an intermediate step in understanding
references. But a true understanding of references is
reached only when one can describe their semantics without
using pointers.

Personally, I see references as means to introduce names
(or aliases) for already-existing objects. So, I'd say that
a reference return means that you grant the caller the
right to bind a name to the refered object. (You see that
I do not use the word »pointer« here.)
 
Ö

Öö Tiib

Can someone help me understand what really happens when a function returns
a reference?

With reference we usually mean a thing that is very similar to immutable
pointers that must point at actual object. If reference refers to temporary
then that increases life-time of such temporary until end of life time of
reference. The main benefit above pointers are those constraints and that
effect.
For instance, there is this function:

http://www.cplusplus.com/reference/vector/vector/operator[]/

Is it really returning a pointer?

No.

All usages of operator[] in example in that article are returning
'std::vector<int,std::allocator<int>>::reference' that must be typedefed as
'std::allocator<int>::reference' that must be typedefed as
'int&' if I understand standard correctly. That 'int&' is ordinary reference
to int.

In general 'std::vector<A,B> operator[](size_type)' must return
'B::reference' and 'std::vector<A,B> operator[](size_type) const' must
return 'B::const_reference' whatever it is. It can be pretty much anything.
 
N

Nobody

In general 'std::vector<A,B> operator[](size_type)' must return
'B::reference' and 'std::vector<A,B> operator[](size_type) const' must
return 'B::const_reference' whatever it is. It can be pretty much anything.

C++11 requires that "std::vector<T,Alloc>::reference" is "T&" (similarly
for the const version). Prior versions only required that it was
"Alloc::reference", which needn't be an actual reference.

Also, std::vector<bool,Alloc> is specialised, and the reference types
typically won't be actual references but proxies which "look like"
references insofar as they provide suitable "operator =" and
"operator bool" methods. This allows the vector to store each element as a
single bit, which precludes the use of actual references.
 
Ö

Öö Tiib

In general 'std::vector<A,B> operator[](size_type)' must return
'B::reference' and 'std::vector<A,B> operator[](size_type) const' must
return 'B::const_reference' whatever it is. It can be pretty much anything.

C++11 requires that "std::vector<T,Alloc>::reference" is "T&" (similarly
for the const version). Prior versions only required that it was
"Alloc::reference", which needn't be an actual reference.

Also, std::vector<bool,Alloc> is specialised, and the reference types
typically won't be actual references but proxies which "look like"
references insofar as they provide suitable "operator =" and
"operator bool" methods. This allows the vector to store each element as a
single bit, which precludes the use of actual references.

Thanks for clarifying! That was unexpected for me. Technically C++11
breaks its own rules if 'std::vector<bool>::reference' is not
'bool&' but 'std::vector<T,X>::reference' (IOW that 'X::reference') MUST
be 'T&'. In previous version that 'vector<bool>' was more useful as it
was at least possible to construct similar family of vectors by using
clever allocators.
 
U

Urs Thuermann

Öö Tiib said:
With reference we usually mean a thing that is very similar to immutable
pointers that must point at actual object. If reference refers to temporary
then that increases life-time of such temporary until end of life time of
reference. The main benefit above pointers are those constraints and that
effect.

I don't think references increase the life-time of the object they
refer to. It's the programmers job to ensure the reference isn't used
after the object it refers to has disappeared. E.g., the following
has undefined behavior and you may get a compiler warning:

class A { int a; };
const A &foo() {
return A();
}

Surprisingly, GCC doesn't see the undefined behavior if you pass the
reference to the temporary object through another function:

class A { int a; };
const A &bar(const A &a) {
return a;
}
const A &foo() {
return bar(A());
}

urs
 
M

Martin Shobe

I don't think references increase the life-time of the object they
refer to. It's the programmers job to ensure the reference isn't used
after the object it refers to has disappeared. E.g., the following
has undefined behavior and you may get a compiler warning:

class A { int a; };
const A &foo() {
return A();
}

Actually, they can. They just don't in that situation. However, the
following code is ok.

#include <iostream>

int foo()
{
return 42;
}

int main()
{
int const & bar = foo();

// Binding the temporary to bar extended it's lifetime.
// See 12.2.5 in n3242.
std::cout << bar << std::endl;

return 0;
}

[snip]

Martin Shobe
 
J

James Kanze

Martin Shobe <[email protected]> wrote:
Basically, temporaries created inside a scope will live for as long as
any reference inside that same scope refers to them, but no longer.

That's false. The lifetime of a temporary will only be extended
to that of the reference it is used to initialize directly.
Other references to the temporary do not extend its lifetime,
e.g.:

int const&
ref( int const& ri )
{
return ri;
}

//
int const& ri = ref( 42 );

will result in a dangling reference.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top