TC++PL(se) section 7.3 Value Return

[Wayne Shu]

Hi everyone:

I am reading Bjarne Stroustrup's The C++ Programming
Language(Special Edition).

In section 7.3, bs wrote "Like the semantics of argument passing,
the semantics of function value return are identical to the semantics
of initialization. A return statement is considered to initialize an
unnamed variable of the returned type."

Is the *unnamed variable* here always create when we call a
function?

For instance, there is a function foo,

int foo(int i)
{
return i*i;
}

when we call it,

int i = foo(5);

Is the above statement mean the following code(not legal in c++)

int tmp = foo(5); // tmp here is the *unnamed variable* bs referred.
int i = tmp;

Even for the build-in types, it is ineffective, why need the *unnamed
variable*?

Regards.

 

[Guest]

Hi everyone:

I am reading Bjarne Stroustrup's The C++ Programming
Language(Special Edition).

In section 7.3, bs wrote "Like the semantics of argument passing,
the semantics of function value return are identical to the semantics
of initialization. A return statement is considered to initialize an
unnamed variable of the returned type."

Is the *unnamed variable* here always create when we call a
function?

For instance, there is a function foo,

int foo(int i)
{
return i*i;
}

when we call it,

int i = foo(5);

Is the above statement mean the following code(not legal in c++)

int tmp = foo(5); // tmp here is the *unnamed variable* bs referred.
int i = tmp;

Even for the build-in types, it is ineffective, why need the *unnamed
variable*?

No, there is something called the named return value optimisation, which
means that instead of creating an temporary and then copying it to the
variable the return value is created directly into the variable. The
following code should demonstrate it:

#include <iostream>

class Foo
{
int v;
public:
Foo(int i) : v(i)
{
std::cout << "Ctor\n";
}
Foo(const Foo& f) : v(f.v)
{
std::cout << "Copy Ctor\n";
}
Foo& operator=(const Foo& f)
{
v = f.v; std::cout << "Assign\n";
}
};

Foo bar(int i)
{
return Foo(i);
}

int main()
{
Foo f = bar(1);
}


If you only get the "Ctor" output the compiler has used the NRVO, if you
also get "Copy Ctor" then it has not.

 

[Markus Schoder]

Stroustrup describes how the program needs to _behave_. Compiler
implementers are free to achieve the same behaviour without introducing
an extra variable. For a built-in type no optimising compiler will use an
extra variable in your case.

No, there is something called the named return value optimisation, which
means that instead of creating an temporary and then copying it to the
variable the return value is created directly into the variable.

RVO allows to elide copy constructor calls even if the behaviour might be
different (for "odd" copy constructor implementations) which is never the
case for built-in types.

Foo bar(int i)
{
return Foo(i);
}

That is actually not RVO. That is a more general case of eliding copy
constructors for temporaries. RVO would look like this:

Foo bar(int i)
{
Foo foo(i);
// can do more stuff with foo here.
return foo;
}

 

[James Kanze]

I am reading Bjarne Stroustrup's The C++ Programming
Language(Special Edition).

In section 7.3, bs wrote "Like the semantics of argument passing,
the semantics of function value return are identical to the semantics
of initialization. A return statement is considered to initialize an
unnamed variable of the returned type."

Is the *unnamed variable* here always create when we call a
function?

No. What do you think Bjarne meant by "is considered to
create", rather than just saying "creates"?

In general, the compiler can do anything it wants, as long as
the "observable behavior" of the program is not modified. In
this particular case, there is even special language to allow
the compiler to suppress the extra object even if doing so
changes the observable behavior.

 

[Siddharth Jain]

A return statement is considered to initialize an

the return statement has to return the value in some unnamed variable
and initialize it with
the returned value, when we call the function in an expression or do
not catch the returned value explicitly in a variable.

That is why it is "A return statement is considered to initialize an
unnamed variable of the returned type." and not always "A return
statement creates and initialize an
unnamed variable of the returned type".