dangling references?

Hello Experts!

I'm reading in a book about C++ and the book says common errors is
"A function should not return a constant references to its parameter passed
by constant references"
Why?
Here I have written a method that has exactly this which is the parameter is
passed by constant references and I return constant references what is it
that can cause common error by writng in this way.

main()
{
int tal = 9;
Test t;
t.foo(tal);
}

class Test
{
const int& foo(const int& i)
{
return i;
}
};

Many thanks
//Tony

re: dangling references?

Tony Johansson wrote:[color=blue]
> Hello Experts!
>
> I'm reading in a book about C++ and the book says common errors is
> "A function should not return a constant references to its parameter passed
> by constant references"
> Why?[/color]

const int& f(const int& i)
{
return i;
}

void bogus()
{
const int& j = f(int());
// j is now dangling
}

The danger is that if you call f with a temporary, as the code above
does, it returns a reference to that temporary, which becomes invalid
when the temporary goes away. That danger doesn't mean you shouldn't do
it, but that if you do, you have to be sure of how you use it.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

re: dangling references?

Tony Johansson wrote:
[color=blue]
> I'm reading in a book about C++[/color]

Could you please cite the book?
[color=blue]
> and the book says that a common error is
>
> "A function should not return a constant references
> to its parameter passed by constant references"[/color]

Can you please cite the passage which contains the above quote?
Can you tell us the name of the author?
[color=blue]
> Why?[/color]
[color=blue]
> Here I have written a method that has exactly this
> [where] the parameter is passed by constant reference
> and I return constant a reference.
> What is it that can cause a common error by writng in this way?[/color]

[color=blue]
> cat main.cc[/color]
#include <iostream>

class Test {
public:
const int& foo(const int& i) const {
return i;
}
};

int main(int argc, char* argv[]) {
int tal = 9;
Test t;
std::cout << "t.foo(" << tal << ") = "
<< t.foo(tal) << std::endl;
return 0;
}
[color=blue]
> g++ -Wall -ansi -pedantic -O2 -o main main.cc
> ./main[/color]
t.foo(9) = 9

It works just fine for me.

My guess is that you have misread the author
and now you are confused.

re: dangling references?

* Tony Johansson:[color=blue]
>
> I'm reading in a book about C++ and the book says common errors is
> "A function should not return a constant references to its parameter passed
> by constant references"
> Why?[/color]

Because the ref-to-const parameter means you can (easily) pass in a temporary,
e.g. the literal number 42, and that temporary will not exist any longer when
evaluation of the expression that the function call occurs in is finished.
Actually it may be destroyed even earlier, as soon as the function returns,
because §5.2.2/4 says "The lifetime of a parameter ends when the function in
which it is defined returns". However, §12.2/5 says "A temporary bound to a
reference parameter in a function call persists until the completion of the
full expression containing the call." Take your pick.

Thus, for a temporary as argument, the function result can only be safely
used inside the expression the function call occurs in. And even there it
might not be safe to use it. Depending on how you read the Holy Standard.

Personally I think §12.2/5 is the most specific and therefore applies, and a
fair amount of code would, I believe, be broken if §5.2.2/4 is the "winner".

[color=blue]
> Here I have written a method that has exactly this which is the parameter is
> passed by constant references and I return constant references what is it
> that can cause common error by writng in this way.
>
> main()[/color]

'main' must have 'int' result type; this should not compile
(unfortunately a certain compiler from a large company allows it).

[color=blue]
> {
> int tal = 9;
> Test t;[/color]

Class 'Test' is not known at this point.

This should not compile.

I don't know any compiler that accepts it.

[color=blue]
> t.foo(tal);[/color]

Any real test would have to use the result.

However, that only tells you what a specific compiler does.

It doesn't tell you whether it's behavior mandated by the standard.

[color=blue]
> }
>
> class Test
> {
> const int& foo(const int& i)
> {
> return i;
> }
> };[/color]

Hth.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

re: dangling references?

On Wed, 06 Apr 2005 20:59:13 +0000, Tony Johansson wrote:
[color=blue]
> Hello Experts!
>
> I'm reading in a book about C++ and the book says common errors is
> "A function should not return a constant references to its parameter passed
> by constant references"
> Why?
> Here I have written a method that has exactly this which is the parameter is
> passed by constant references and I return constant references what is it
> that can cause common error by writng in this way.
>
> main()
> {
> int tal = 9;
> Test t;
> t.foo(tal);
> }
>
> class Test
> {
> const int& foo(const int& i)
> {
> return i;
> }
> };
>
> Many thanks
> //Tony[/color]

You can bind a temporary to a const reference. What if you did:

t.foo(9);

Here's another example:

#include <iostream>

class A
{
public:
A() { i = 3; }
~A() { i = 5; }
int GetI() const { return i; }
private:
int i;
};

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

int main()
{
const A& a = foo(A());
std::cout << a.GetI() << std::endl;
}

gcc gives "5" (though I suspect we've entered into undefined behavior at
this point).

- Jay

re: dangling references?

Alf P. Steinbach wrote:[color=blue]
> * Tony Johansson:[color=green]
> >
> > I'm reading in a book about C++ and the book says common errors is
> > "A function should not return a constant references to its[/color][/color]
parameter passed[color=blue][color=green]
> > by constant references"
> > Why?[/color]
>
> Because the ref-to-const parameter means you can (easily) pass in a[/color]
temporary,[color=blue]
> e.g. the literal number 42, and that temporary will not exist any[/color]
longer when[color=blue]
> evaluation of the expression that the function call occurs in is[/color]
finished.[color=blue]
> Actually it may be destroyed even earlier, as soon as the function[/color]
returns,[color=blue]
> because §5.2.2/4 says "The lifetime of a parameter ends when the[/color]
function in[color=blue]
> which it is defined returns".[/color]

No, 5.2.2/4 talks about the reference parameter and not the object
to which the reference is bound. Compare:

void foo() {
int i = 0;
{
int const& ri = i;
}
}
The lifetime of ri ends at the first }, but the lifetime of i ends
at the second }.
The fact that the reference is bound to a temporary doesn't matter
here. The only case in which a temporary is destroyed due to the
end of the lifetime of a reference is when the temporary would have
been destoyed earlier in the absence of the reference. I.e.
references can extend lifetimes but not shorten them.

Regards,
Michiel Salters

re: dangling references?

* msalters:[color=blue]
>
> Alf P. Steinbach wrote:[color=green]
> > * Tony Johansson:[color=darkred]
> > >
> > > I'm reading in a book about C++ and the book says common errors is
> > > "A function should not return a constant references to its[/color][/color]
> parameter passed[color=green][color=darkred]
> > > by constant references"
> > > Why?[/color]
> >
> > Because the ref-to-const parameter means you can (easily) pass in a[/color]
> temporary,[color=green]
> > e.g. the literal number 42, and that temporary will not exist any[/color]
> longer when[color=green]
> > evaluation of the expression that the function call occurs in is[/color]
> finished.[color=green]
> > Actually it may be destroyed even earlier, as soon as the function[/color]
> returns,[color=green]
> > because =A75.2.2/4 says "The lifetime of a parameter ends when the[/color]
> function in[color=green]
> > which it is defined returns".[/color]
>
> No, 5.2.2/4 talks about the reference parameter and not the object
> to which the reference is bound. Compare:
>
> void foo() {
> int i =3D 0;
> {
> int const& ri =3D i;
> }
> }
> The lifetime of ri ends at the first }, but the lifetime of i ends
> at the second }.[/color]

On reflection I think you're right.

Which means my tentative conclusion in the posting the above was a follow-up
to was right, for the wrong reasons.

However, I also think the standard is unclear & even misleading here.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?