TC++PL(se) section 7.3 Value Return



 DEVELOP > c-Plus-Plus > TC++PL(se) section 7.3 Value Return

LINK TO THIS PAGE  


rating :  0   |  0


  Page 1 of 1

1

 
Topic: DEVELOP > c-Plus-Plus
User: "Wayne Shu"
Date: 12 Aug 2007 08:48:52 AM
Object: TC++PL(se) section 7.3 Value Return
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.
.

User: "=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?="

Title: Re: TC++PL(se) section 7.3 Value Return 12 Aug 2007 09:06:52 AM
On 2007-08-12 15:48, Wayne Shu wrote:

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.
--
Erik Wikström
.
User: "Markus Schoder"

Title: Re: TC++PL(se) section 7.3 Value Return 12 Aug 2007 10:05:03 AM
On Sun, 12 Aug 2007 14:06:52 +0000, Erik Wikström wrote:

On 2007-08-12 15:48, Wayne Shu wrote:

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

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;
}
--
Markus Schoder
.


User: "James Kanze"

Title: Re: TC++PL(se) section 7.3 Value Return 12 Aug 2007 10:59:39 AM
On Aug 12, 3:48 pm, Wayne Shu <Wayne...@gmail.com> wrote:

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.
--
James Kanze (GABI Software) email:james.ka...@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
.
User: "Siddharth Jain"

Title: Re: TC++PL(se) section 7.3 Value Return 14 Aug 2007 01:26:43 AM
On Aug 12, 8:59 pm, James Kanze <james.ka...@gmail.com> wrote:

On Aug 12, 3:48 pm, Wayne Shu <Wayne...@gmail.com> wrote:

A return statement is considered to initialize an

unnamed variable of the returned type."

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".
.



  Page 1 of 1

1

 


Related Articles
 

NEWER

pg.1232     pg.940     pg.716     pg.544     pg.412     pg.311     pg.234     pg.175     pg.130     pg.96     pg.70     pg.50     pg.35     pg.24     pg.16     pg.10     pg.6     pg.3     pg.1

OLDER