int& foo() {} works well?

[bingfeng]

hello,
anyone else can explain why following codes give wrong result while
compiler accept it still?

int & foo() {}
int main()
{
int x = foo;
std::cout << x << std::endl;
}

thanks!

[Kai-Uwe Bux]

bingfeng wrote:

hello,
anyone else can explain why following codes give wrong result while
compiler accept it still?

int & foo() {}
int main()
{
int x = foo;
std::cout << x << std::endl;
}

After including the missing headers, I still get an error:

invalid conversion from 'int& (*)()' to 'int'

So changing

int x = foo;

to

int x = foo();

I get a clean compile but undefined behavior, e.g., as per [6.6.3/2].
As for _why_ the standard specifies undefined behavior for falling through
the end of a function that has to return something, one has to recall that
it is generally undecidable which paths of a function can be taken for
possible input values. In the most common cases, it is easy but still a
burden on the compiler that the C++ standard does not wish to impose.
Best

Kai-Uwe Bux

[Pete Becker]

On 2008-10-17 06:17:59 -0400, Kai-Uwe Bux <jk********@gmx.netsaid:

bingfeng wrote:

>hello,
anyone else can explain why following codes give wrong result while
compiler accept it still?

int & foo() {}
int main()
{
int x = foo;
std::cout << x << std::endl;
}

After including the missing headers, I still get an error:

invalid conversion from 'int& (*)()' to 'int'

So changing

int x = foo;

to

int x = foo();

I get a clean compile but undefined behavior, e.g., as per [6.6.3/2].
As for _why_ the standard specifies undefined behavior for falling through
the end of a function that has to return something, one has to recall that
it is generally undecidable which paths of a function can be taken for
possible input values. In the most common cases, it is easy but still a
burden on the compiler that the C++ standard does not wish to impose.

In addition, most compilers will give a warning on something as simple
as the code above. So they'll find the obvious problems, but not the
subtle ones.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[bingfeng]

Thanks, Pete and Kai, I was misled to check how initialiate a
reference in standard text found nothing of course. Common used g++
(3.4.5) and MSVC compiler keep silence on this both.
Sorry for my typo in original post, Kai.

On 10ÔÂ17ÈÕ, ÏÂÎç7ʱ18·Ö, Pete Becker <[e-mail]:

On 2008-10-17 06:17:59 -0400, Kai-Uwe Bux <[e-mail]:

bingfeng wrote:

hello,
anyone else can explain why following codes give wrong result while
compiler accept it still?

int & foo() {}
int main()
{
int x = foo;
std::cout << x << std::endl;
}

After including the missing headers, I still get an error:

invalid conversion from 'int& (*)()' to 'int'

So changing

int x = foo;

to

int x = foo();

I get a clean compile but undefined behavior, e.g., as per [6.6.3/2].

As for _why_ the standard specifies undefined behavior for falling through
the end of a function that has to return something, one has to recall that
it is generally undecidable which paths of a function can be taken for
possible input values. In the most common cases, it is easy but still a
burden on the compiler that the C++ standard does not wish to impose.

In addition, most compilers will give a warning on something as simple
as the code above. So they'll find the obvious problems, but not the
subtle ones.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)