Binding reference to an R-value

[Frederick Gotham]

We all know that there's special rules for the binding of a "reference to
const" to an R-value, i.e.:

int const &i = 5;

acts as if it were:

int const __rval = 5;

int const &i = __rval;

Consider the following function:

int const &Func()
{
int i = 7;

return i;
}

We see that the reference is bound to an L-value in the return statement,
and so the "bind reference to const to R-value" rules don't apply. Must the
return statement be rewritten as the following?

return (int)i;

in order to enforce the rules for binding a "reference to const" to an R-
value? Or is the function just destined to fail?

Here's a program to demonstrate:

#include <iostream>
#include <ostream>

using std::cout;
using std::endl;

int const &Func()
{
int i = 7;

return (int)i;
}

int main()
{
cout << Func() << endl;
}

--

Frederick Gotham

[AnonMail2005]

Frederick Gotham wrote:

We all know that there's special rules for the binding of a "reference to
const" to an R-value, i.e.:

int const &i = 5;

acts as if it were:

int const __rval = 5;

int const &i = __rval;

Consider the following function:

int const &Func()
{
int i = 7;

return i;
}

We see that the reference is bound to an L-value in the return statement,
and so the "bind reference to const to R-value" rules don't apply. Must the
return statement be rewritten as the following?

return (int)i;

in order to enforce the rules for binding a "reference to const" to an R-
value? Or is the function just destined to fail?

Here's a program to demonstrate:

#include <iostream>
#include <ostream>

using std::cout;
using std::endl;

int const &Func()
{
int i = 7;

return (int)i;
}

int main()
{
cout << Func() << endl;
}

--

Frederick Gotham

In order to return a reference from Func, you must return a reference
to something that exists after Func returns. Variables defined on
the stack do not satisfy this requirement.

One example which is the classic Meyer's singleton:

int const & Func ()
{
static int i = 7;
return i;
}

There are others, but I don't know what your requirements are.

[Frederick Gotham]

An**********@gmail.com posted:

In order to return a reference from Func, you must return a reference
to something that exists after Func returns.

Acknowledged.

Variables defined on the stack do not satisfy this requirement.

Acknowledged.

One example which is the classic Meyer's singleton:

int const & Func ()
{
static int i = 7;
return i;
}

There are others, but I don't know what your requirements are.

The code in my original post explained.
--

Frederick Gotham

[Kai-Uwe Bux]

Frederick Gotham wrote:

>
We all know that there's special rules for the binding of a "reference to
const" to an R-value, i.e.:

int const &i = 5;

acts as if it were:

int const __rval = 5;

int const &i = __rval;

Consider the following function:

int const &Func()
{
int i = 7;

return i;
}

We see that the reference is bound to an L-value in the return statement,
and so the "bind reference to const to R-value" rules don't apply. Must
the return statement be rewritten as the following?

return (int)i;

in order to enforce the rules for binding a "reference to const" to an R-
value? Or is the function just destined to fail?

[snip]

I think

return int(i);

should be fine. As far as I can see, int(i) will construct a temporary int
r-value that binds nicely to the const int &. Since I have no idea what
kind of black magic a C-style cast performs, I cannot comment on

return (int)i;
Best

Kai-Uwe Bux

[Alf P. Steinbach]

* Kai-Uwe Bux:

Frederick Gotham wrote:

>>
int const &Func()
{
int i = 7;

return i;
}

I think

return int(i);

should be fine. As far as I can see, int(i) will construct a temporary int
r-value that binds nicely to the const int &.

Unfortunately that temporary ceases to exist immediately afterwards,
since execution leaves the scope where it's created, which yields UB.

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

[Kai-Uwe Bux]

Alf P. Steinbach wrote:

* Kai-Uwe Bux:

>Frederick Gotham wrote:

>>>
int const &Func()
{
int i = 7;

return i;
}

I think

return int(i);

should be fine. As far as I can see, int(i) will construct a temporary
int r-value that binds nicely to the const int &.

Unfortunately that temporary ceases to exist immediately afterwards,
since execution leaves the scope where it's created, which yields UB.

Oops, you are right.
Thanks

Kai-Uwe Bux

[Frederick Gotham]

Kai-Uwe Bux posted:

Since I have no idea what kind of black magic a C-style cast performs, I
cannot comment on

return (int)i;

int(i) and (int)i are exactly equivalent in all contexts, with all types.

--

Frederick Gotham

[Frederick Gotham]

Kai-Uwe Bux posted:

>Unfortunately that temporary ceases to exist immediately afterwards,
since execution leaves the scope where it's created, which yields UB.

Oops, you are right.

I'm not so sure about that.

The reference which is returned by the function should have scope _outside_
of the function, should it not?
--

Frederick Gotham

[Alf P. Steinbach]

* Frederick Gotham:

Kai-Uwe Bux posted:

>>Unfortunately that temporary ceases to exist immediately afterwards,
since execution leaves the scope where it's created, which yields UB.

Oops, you are right.

I'm not so sure about that.

The reference which is returned by the function should have scope _outside_
of the function, should it not?

Nope. Or rather yes, if by scope you mean lifetime, but the language
doesn't do that for you.

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

[Kai-Uwe Bux]

Frederick Gotham wrote:

Kai-Uwe Bux posted:

>>Unfortunately that temporary ceases to exist immediately afterwards,
since execution leaves the scope where it's created, which yields UB.

Oops, you are right.

I'm not so sure about that.

The reference which is returned by the function should have scope
_outside_ of the function, should it not?

I don't think so, but I might be off. Here is what I found in the standard
[12.2/5]:

... A temporary bound to the returned value in a function return statement
(6.6.3) persists until the function exits. ...
So even if the temporary exists outside the function, it won't exist very
long.
Best

Kai-Uwe Bux

[Old Wolf]

Frederick Gotham wrote:

Kai-Uwe Bux posted:

Since I have no idea what kind of black magic a C-style cast performs, I
cannot comment on

return (int)i;

int(i) and (int)i are exactly equivalent in all contexts, with all types.

Except the following contexts (among others):

#include <iostream>
int i = 5;

int main()
{
int(i);
std::cout << "i = " << i << "\n";
}

int *fred2()
{
return new int(i);
}

[Frederick Gotham]

Old Wolf posted:

Frederick Gotham wrote:

>Kai-Uwe Bux posted:

Since I have no idea what kind of black magic a C-style cast performs,

I

cannot comment on

return (int)i;

int(i) and (int)i are exactly equivalent in all contexts, with all

types.

>
Except the following contexts (among others):

new int(i)

Yes. In the context of casting though, they're always equivalent.

When using new, it's an implicit conversion rather than a hardcore cast, as
demonstrated by the type mismatch in the following:

int main()
{
double *p = 0;

new int(p);
}

While we're playing grammar games, you could have also said:

sizeof (int)i

Vs.

sizeof int(i)

--

Frederick Gotham