On Oct 14, 10:00 pm, Erik-wikst...@telia.com (Erik Wikström) wrote:
> On 2007-10-14 21:19, terminator wrote:
>
>
>
>
>
> > On Oct 14, 11:08 am, Greg Herlihy <gre...@pacbell.net> wrote:
> >> On Oct 9, 8:56 am, "terminator(jam)" <farid.mehr...@gmail.com> wrote:
>
> >> > consider:
>
> >> > struct memory_pig{//a really large type:
>
> >> > memory_pig(){
> >> > std::cout<<"mem pig default\n";
> >> > //etc...
> >> > };
>
> >> > memory_pig(memory_pig const&){
> >> > std::cout<<"mem pig copy\n";
> >> > //etc...
> >> > };
>
> >> > ~memory_pig(){
> >> > std::cout<<"mem pig finish\n";
> >> > //etc...
> >> > };
>
> >> > //etc...
>
> >> > };///struct memory_pig
>
> >> > memory_pig foo(){
> >> > memory_pig result;
> >> > result=something;
> >> > //etc...
> >> > result=something_else;
> >> > return result;
>
> >> > };
>
> >> > any time 'foo' is called the output will contain the following
> >> > sequence:
>
> >> > mem pig default
> >> > mem pig copy
> >> > mem pig finish
>
> >> > the last line of output may repeat based on how the result is
> >> > stored(rvo) or not.
> >> > So,two objects of a large type will be constructed and at least one is
> >> > destructed on every call to 'foo'
>
> >> The C++ Standard already allows the "(Named) Return Value
> >> Optimization" (NRVO or RVO for short). The optimization allows (under
> >> certain conditions) the compiler to construct the result of a function
> >> call "in place" - that is, directly in the object initialized with the
> >> function call result.
>
> >> So, to take advantage of this optimization, a program should use the
> >> result of a function call to initialize an object, instead of
> >> assigning the function result to an existing object.
>
> >> For example:
>
> >> #include <iostream>
>
> >> using std::cout;
>
> >> struct memory_pig
> >> { // a really large type:
> >> memory_pig()
> >> {
> >> cout << "mem pig default\n";
> >> }
> >> memory_pig(memory_pig const&)
> >> {
> >> cout << "mem pig copy\n";
> >> }
> >> ~memory_pig()
> >> {
> >> cout << "mem pig finish\n";
> >> }
> >> };
>
> >> memory_pig foo()
> >> {
> >> memory_pig result;
> >> // ...
> >> return result;
> >> }
>
> >> int main()
> >> {
> >> memory_pig m1 = foo();
> >> memory_pig m2 = foo();
> >> memory_pig m3 = foo();
> >> }
>
> >> I compiled the above program twice, once with and once without NRVO.
> >> The output of both programs is shown in the two columns below. As this
> >> comparison shows, NRVO can be a particular effective optimization -
> >> even for a small C++ program like the one used in this example.
>
> > I knew about RVO but not NRVO(that is what I am talking about).Is NRVO
> > standard behavoir or unspecified?
> > At least my compiler does not perform the NRVO.
>
> The standard allows this optimisation, but it does not require it (see
> section 12.8 paragraph 15). I think that most newer compilers support
> it, but you might have to turn up the optimisation level a bit.
>
> One important thing to remember is that when NRVO is in use the
> destructor will not be called for the local object, nor will the copy-
> constructor for the non-local object (m1 to m3 in the code above) be
> called. Thus you should not depend on any side effects that the copy-
> constructor or destructor might have.
>

prior to return and after return are two different case to me:I mean
before return even move should be disabled ,while after the return
either of move/copy must perform .

regards,
FM.


---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

===================================== MODERATOR'S COMMENT:

Please trim unnecessary material when replying.


===================================== END OF MODERATOR'S COMMENT
On 2007-10-15 17:52, terminator(jam) wrote:
> On Oct 14, 10:00 pm, Erik-wikst...@telia.com (Erik Wikström) wrote:
>> On 2007-10-14 21:19, terminator wrote:
>>
>>
>>
>>
>>
>> > On Oct 14, 11:08 am, Greg Herlihy <gre...@pacbell.net> wrote:
>> >> On Oct 9, 8:56 am, "terminator(jam)" <farid.mehr...@gmail.com> wrote:
>>
>> >> > consider:
>>
>> >> > struct memory_pig{//a really large type:
>>
>> >> > memory_pig(){
>> >> > std::cout<<"mem pig default\n";
>> >> > //etc...
>> >> > };
>>
>> >> > memory_pig(memory_pig const&){
>> >> > std::cout<<"mem pig copy\n";
>> >> > //etc...
>> >> > };
>>
>> >> > ~memory_pig(){
>> >> > std::cout<<"mem pig finish\n";
>> >> > //etc...
>> >> > };
>>
>> >> > //etc...
>>
>> >> > };///struct memory_pig
>>
>> >> > memory_pig foo(){
>> >> > memory_pig result;
>> >> > result=something;
>> >> > //etc...
>> >> > result=something_else;
>> >> > return result;
>>
>> >> > };
>>
>> >> > any time 'foo' is called the output will contain the following
>> >> > sequence:
>>
>> >> > mem pig default
>> >> > mem pig copy
>> >> > mem pig finish
>>
>> >> > the last line of output may repeat based on how the result is
>> >> > stored(rvo) or not.
>> >> > So,two objects of a large type will be constructed and at least one is
>> >> > destructed on every call to 'foo'
>>
>> >> The C++ Standard already allows the "(Named) Return Value
>> >> Optimization" (NRVO or RVO for short). The optimization allows (under
>> >> certain conditions) the compiler to construct the result of a function
>> >> call "in place" - that is, directly in the object initialized with the
>> >> function call result.
>>
>> >> So, to take advantage of this optimization, a program should use the
>> >> result of a function call to initialize an object, instead of
>> >> assigning the function result to an existing object.
>>
>> >> For example:
>>
>> >> #include <iostream>
>>
>> >> using std::cout;
>>
>> >> struct memory_pig
>> >> { // a really large type:
>> >> memory_pig()
>> >> {
>> >> cout << "mem pig default\n";
>> >> }
>> >> memory_pig(memory_pig const&)
>> >> {
>> >> cout << "mem pig copy\n";
>> >> }
>> >> ~memory_pig()
>> >> {
>> >> cout << "mem pig finish\n";
>> >> }
>> >> };
>>
>> >> memory_pig foo()
>> >> {
>> >> memory_pig result;
>> >> // ...
>> >> return result;
>> >> }
>>
>> >> int main()
>> >> {
>> >> memory_pig m1 = foo();
>> >> memory_pig m2 = foo();
>> >> memory_pig m3 = foo();
>> >> }
>>
>> >> I compiled the above program twice, once with and once without NRVO.
>> >> The output of both programs is shown in the two columns below. As this
>> >> comparison shows, NRVO can be a particular effective optimization -
>> >> even for a small C++ program like the one used in this example.
>>
>> > I knew about RVO but not NRVO(that is what I am talking about).Is NRVO
>> > standard behavoir or unspecified?
>> > At least my compiler does not perform the NRVO.
>>
>> The standard allows this optimisation, but it does not require it (see
>> section 12.8 paragraph 15). I think that most newer compilers support
>> it, but you might have to turn up the optimisation level a bit.
>>
>> One important thing to remember is that when NRVO is in use the
>> destructor will not be called for the local object, nor will the copy-
>> constructor for the non-local object (m1 to m3 in the code above) be
>> called. Thus you should not depend on any side effects that the copy-
>> constructor or destructor might have.
>>
>
> prior to return and after return are two different case to me:I mean
> before return even move should be disabled ,while after the return
> either of move/copy must perform .

Sorry, but you lost me there, what move? Of what to where?

--
Erik Wikström

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

On Oct 15, 8:35 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
> ===================================== MODERATOR'S COMMENT:
>
> Please trim unnecessary material when replying.
>
> ===================================== END OF MODERATOR'S COMMENT
> On 2007-10-15 17:52, terminator(jam) wrote:
>
>
>
>
>
> > On Oct 14, 10:00 pm, Erik-wikst...@telia.com (Erik Wikström) wrote:
> >> On 2007-10-14 21:19, terminator wrote:
>
> >> > On Oct 14, 11:08 am, Greg Herlihy <gre...@pacbell.net> wrote:
> >> >> On Oct 9, 8:56 am, "terminator(jam)" <farid.mehr...@gmail.com> wrote:
>
> >> >> > consider:
>
> >> >> > struct memory_pig{//a really large type:
>
> >> >> > memory_pig(){
> >> >> > std::cout<<"mem pig default\n";
> >> >> > //etc...
> >> >> > };
>
> >> >> > memory_pig(memory_pig const&){
> >> >> > std::cout<<"mem pig copy\n";
> >> >> > //etc...
> >> >> > };
>
> >> >> > ~memory_pig(){
> >> >> > std::cout<<"mem pig finish\n";
> >> >> > //etc...
> >> >> > };
>
> >> >> > //etc...
>
> >> >> > };///struct memory_pig
>
> >> >> > memory_pig foo(){
> >> >> > memory_pig result;
> >> >> > result=something;
> >> >> > //etc...
> >> >> > result=something_else;
> >> >> > return result;
>
> >> >> > };
>
> >> >> > any time 'foo' is called the output will contain the following
> >> >> > sequence:
>
> >> >> > mem pig default
> >> >> > mem pig copy
> >> >> > mem pig finish
>
> >> >> > the last line of output may repeat based on how the result is
> >> >> > stored(rvo) or not.
> >> >> > So,two objects of a large type will be constructed and at least one is
> >> >> > destructed on every call to 'foo'
>
> >> >> The C++ Standard already allows the "(Named) Return Value
> >> >> Optimization" (NRVO or RVO for short). The optimization allows (under
> >> >> certain conditions) the compiler to construct the result of a function
> >> >> call "in place" - that is, directly in the object initialized with the
> >> >> function call result.
>
> >> >> So, to take advantage of this optimization, a program should use the
> >> >> result of a function call to initialize an object, instead of
> >> >> assigning the function result to an existing object.
>
> >> >> For example:
>
> >> >> #include <iostream>
>
> >> >> using std::cout;
>
> >> >> struct memory_pig
> >> >> { // a really large type:
> >> >> memory_pig()
> >> >> {
> >> >> cout << "mem pig default\n";
> >> >> }
> >> >> memory_pig(memory_pig const&)
> >> >> {
> >> >> cout << "mem pig copy\n";
> >> >> }
> >> >> ~memory_pig()
> >> >> {
> >> >> cout << "mem pig finish\n";
> >> >> }
> >> >> };
>
> >> >> memory_pig foo()
> >> >> {
> >> >> memory_pig result;
> >> >> // ...
> >> >> return result;
> >> >> }
>
> >> >> int main()
> >> >> {
> >> >> memory_pig m1 = foo();
> >> >> memory_pig m2 = foo();
> >> >> memory_pig m3 = foo();
> >> >> }
>
> >> >> I compiled the above program twice, once with and once without NRVO.
> >> >> The output of both programs is shown in the two columns below. As this
> >> >> comparison shows, NRVO can be a particular effective optimization -
> >> >> even for a small C++ program like the one used in this example.
>
> >> > I knew about RVO but not NRVO(that is what I am talking about).Is NRVO
> >> > standard behavoir or unspecified?
> >> > At least my compiler does not perform the NRVO.
>
> >> The standard allows this optimisation, but it does not require it (see
> >> section 12.8 paragraph 15). I think that most newer compilers support
> >> it, but you might have to turn up the optimisation level a bit.
>
> >> One important thing to remember is that when NRVO is in use the
> >> destructor will not be called for the local object, nor will the copy-
> >> constructor for the non-local object (m1 to m3 in the code above) be
> >> called. Thus you should not depend on any side effects that the copy-
> >> constructor or destructor might have.
>
> > prior to return and after return are two different case to me:I mean
> > before return even move should be disabled ,while after the return
> > either of move/copy must perform .
>
> Sorry, but you lost me there, what move? Of what to where?
>

Move ctor of course.

regards,
FM.


---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

On 2007-10-16 19:55, terminator(jam) wrote:
> On Oct 15, 8:35 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:

>> On 2007-10-15 17:52, terminator(jam) wrote:

>> > On Oct 14, 10:00 pm, Erik-wikst...@telia.com (Erik Wikström) wrote:
>> >> On 2007-10-14 21:19, terminator wrote:
>>
>> >> > On Oct 14, 11:08 am, Greg Herlihy <gre...@pacbell.net> wrote:
>> >> >> On Oct 9, 8:56 am, "terminator(jam)" <farid.mehr...@gmail.com> wrote:

>> >> >> The C++ Standard already allows the "(Named) Return Value
>> >> >> Optimization" (NRVO or RVO for short). The optimization allows (under
>> >> >> certain conditions) the compiler to construct the result of a function
>> >> >> call "in place" - that is, directly in the object initialized with the
>> >> >> function call result.
>>
>> >> >> So, to take advantage of this optimization, a program should usethe
>> >> >> result of a function call to initialize an object, instead of
>> >> >> assigning the function result to an existing object.
>>
>> >> >> For example:
>>
>> >> >> #include <iostream>
>>
>> >> >> using std::cout;
>>
>> >> >> struct memory_pig
>> >> >> { // a really large type:
>> >> >> memory_pig()
>> >> >> {
>> >> >> cout << "mem pig default\n";
>> >> >> }
>> >> >> memory_pig(memory_pig const&)
>> >> >> {
>> >> >> cout << "mem pig copy\n";
>> >> >> }
>> >> >> ~memory_pig()
>> >> >> {
>> >> >> cout << "mem pig finish\n";
>> >> >> }
>> >> >> };
>>
>> >> >> memory_pig foo()
>> >> >> {
>> >> >> memory_pig result;
>> >> >> // ...
>> >> >> return result;
>> >> >> }
>>
>> >> >> int main()
>> >> >> {
>> >> >> memory_pig m1 = foo();
>> >> >> memory_pig m2 = foo();
>> >> >> memory_pig m3 = foo();
>> >> >> }
>>
>> >> >> I compiled the above program twice, once with and once without NRVO.
>> >> >> The output of both programs is shown in the two columns below. As this
>> >> >> comparison shows, NRVO can be a particular effective optimization -
>> >> >> even for a small C++ program like the one used in this example.
>>
>> >> > I knew about RVO but not NRVO(that is what I am talking about).IsNRVO
>> >> > standard behavoir or unspecified?
>> >> > At least my compiler does not perform the NRVO.
>>
>> >> The standard allows this optimisation, but it does not require it (see
>> >> section 12.8 paragraph 15). I think that most newer compilers support
>> >> it, but you might have to turn up the optimisation level a bit.
>>
>> >> One important thing to remember is that when NRVO is in use the
>> >> destructor will not be called for the local object, nor will the copy-
>> >> constructor for the non-local object (m1 to m3 in the code above) be
>> >> called. Thus you should not depend on any side effects that the copy-
>> >> constructor or destructor might have.
>>
>> > prior to return and after return are two different case to me:I mean
>> > before return even move should be disabled ,while after the return
>> > either of move/copy must perform .
>>
>> Sorry, but you lost me there, what move? Of what to where?
>>
>
> Move ctor of course.

Sorry, but I still do not understand. What do you mean with RNVO should
be disabled before return but not after? It is something that is
performed *during* return.

--
Erik Wikström

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

On Oct 16, 9:37 pm, Erik-wikst...@telia.com (Erik Wikström) wrote:
> On 2007-10-16 19:55, terminator(jam) wrote:
>
>
>
>
>
> > On Oct 15, 8:35 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
> >> On 2007-10-15 17:52, terminator(jam) wrote:
> >> > On Oct 14, 10:00 pm, Erik-wikst...@telia.com (Erik Wikström) wrote:
> >> >> On 2007-10-14 21:19, terminator wrote:
>
> >> >> > On Oct 14, 11:08 am, Greg Herlihy <gre...@pacbell.net> wrote:
> >> >> >> On Oct 9, 8:56 am, "terminator(jam)" <farid.mehr...@gmail.com> wrote:
> >> >> >> The C++ Standard already allows the "(Named) Return Value
> >> >> >> Optimization" (NRVO or RVO for short). The optimization allows (under
> >> >> >> certain conditions) the compiler to construct the result of a function
> >> >> >> call "in place" - that is, directly in the object initialized with the
> >> >> >> function call result.
>
> >> >> >> So, to take advantage of this optimization, a program should use the
> >> >> >> result of a function call to initialize an object, instead of
> >> >> >> assigning the function result to an existing object.
>
> >> >> >> For example:
>
> >> >> >> #include <iostream>
>
> >> >> >> using std::cout;
>
> >> >> >> struct memory_pig
> >> >> >> { // a really large type:
> >> >> >> memory_pig()
> >> >> >> {
> >> >> >> cout << "mem pig default\n";
> >> >> >> }
> >> >> >> memory_pig(memory_pig const&)
> >> >> >> {
> >> >> >> cout << "mem pig copy\n";
> >> >> >> }
> >> >> >> ~memory_pig()
> >> >> >> {
> >> >> >> cout << "mem pig finish\n";
> >> >> >> }
> >> >> >> };
>
> >> >> >> memory_pig foo()
> >> >> >> {
> >> >> >> memory_pig result;
> >> >> >> // ...
> >> >> >> return result;
> >> >> >> }
>
> >> >> >> int main()
> >> >> >> {
> >> >> >> memory_pig m1 = foo();
> >> >> >> memory_pig m2 = foo();
> >> >> >> memory_pig m3 = foo();
> >> >> >> }
>
> >> >> >> I compiled the above program twice, once with and once without NRVO.
> >> >> >> The output of both programs is shown in the two columns below. As this
> >> >> >> comparison shows, NRVO can be a particular effective optimization -
> >> >> >> even for a small C++ program like the one used in this example.
>
> >> >> > I knew about RVO but not NRVO(that is what I am talking about).Is NRVO
> >> >> > standard behavoir or unspecified?
> >> >> > At least my compiler does not perform the NRVO.
>
> >> >> The standard allows this optimisation, but it does not require it (see
> >> >> section 12.8 paragraph 15). I think that most newer compilers support
> >> >> it, but you might have to turn up the optimisation level a bit.
>
> >> >> One important thing to remember is that when NRVO is in use the
> >> >> destructor will not be called for the local object, nor will the copy-
> >> >> constructor for the non-local object (m1 to m3 in the code above) be
> >> >> called. Thus you should not depend on any side effects that the copy-
> >> >> constructor or destructor might have.
>
> >> > prior to return and after return are two different case to me:I mean
> >> > before return even move should be disabled ,while after the return
> >> > either of move/copy must perform .
>
> >> Sorry, but you lost me there, what move? Of what to where?
>
> > Move ctor of course.
>
> Sorry, but I still do not understand. What do you mean with RNVO should
> be disabled before return but not after? It is something that is
> performed *during* return.

I mean the whole concept of optimization(rvo,nrvo,etc). IMHO:
If a function always returns the same local object the returned object
must be the local object itself rather than a copy/move version of the
local.
If a function returns one of its parameter values returned object is
copy/moved from that parameter because a change in location of the
object is almost inevitable.
If an object is constructed with an rvalue it should be copy/moved.

regards,
FM



---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

On 2007-10-17 17:53, terminator(jam) wrote:
> On Oct 16, 9:37 pm, Erik-wikst...@telia.com (Erik Wikström) wrote:
>> On 2007-10-16 19:55, terminator(jam) wrote:
>> > On Oct 15, 8:35 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
>> >> On 2007-10-15 17:52, terminator(jam) wrote:
>> >> > On Oct 14, 10:00 pm, Erik-wikst...@telia.com (Erik Wikström)wrote:
>> >> >> On 2007-10-14 21:19, terminator wrote:
>>
>> >> >> > On Oct 14, 11:08 am, Greg Herlihy <gre...@pacbell.net> wrote:
>> >> >> >> On Oct 9, 8:56 am, "terminator(jam)" <farid.mehr...@gmail.com> wrote:
>> >> >> >> The C++ Standard already allows the "(Named) Return Value
>> >> >> >> Optimization" (NRVO or RVO for short). The optimization allows (under
>> >> >> >> certain conditions) the compiler to construct the result of afunction
>> >> >> >> call "in place" - that is, directly in the object initializedwith the
>> >> >> >> function call result.
>>
>> >> >> >> So, to take advantage of this optimization, a program should use the
>> >> >> >> result of a function call to initialize an object, instead of
>> >> >> >> assigning the function result to an existing object.
>>
>> >> >> >> For example:
>>
>> >> >> >> #include <iostream>
>>
>> >> >> >> using std::cout;
>>
>> >> >> >> struct memory_pig
>> >> >> >> { // a really large type:
>> >> >> >> memory_pig()
>> >> >> >> {
>> >> >> >> cout << "mem pig default\n";
>> >> >> >> }
>> >> >> >> memory_pig(memory_pig const&)
>> >> >> >> {
>> >> >> >> cout << "mem pig copy\n";
>> >> >> >> }
>> >> >> >> ~memory_pig()
>> >> >> >> {
>> >> >> >> cout << "mem pig finish\n";
>> >> >> >> }
>> >> >> >> };
>>
>> >> >> >> memory_pig foo()
>> >> >> >> {
>> >> >> >> memory_pig result;
>> >> >> >> // ...
>> >> >> >> return result;
>> >> >> >> }
>>
>> >> >> >> int main()
>> >> >> >> {
>> >> >> >> memory_pig m1 = foo();
>> >> >> >> memory_pig m2 = foo();
>> >> >> >> memory_pig m3 = foo();
>> >> >> >> }
>>
>> >> >> >> I compiled the above program twice, once with and once without NRVO.
>> >> >> >> The output of both programs is shown in the two columns below.. As this
>> >> >> >> comparison shows, NRVO can be a particular effective optimization -
>> >> >> >> even for a small C++ program like the one used in this example.
>>
>> >> >> > I knew about RVO but not NRVO(that is what I am talking about)..Is NRVO
>> >> >> > standard behavoir or unspecified?
>> >> >> > At least my compiler does not perform the NRVO.
>>
>> >> >> The standard allows this optimisation, but it does not require it (see
>> >> >> section 12.8 paragraph 15). I think that most newer compilers support
>> >> >> it, but you might have to turn up the optimisation level a bit.
>>
>> >> >> One important thing to remember is that when NRVO is in use the
>> >> >> destructor will not be called for the local object, nor will thecopy-
>> >> >> constructor for the non-local object (m1 to m3 in the code above) be
>> >> >> called. Thus you should not depend on any side effects that the copy-
>> >> >> constructor or destructor might have.
>>
>> >> > prior to return and after return are two different case to me:I mean
>> >> > before return even move should be disabled ,while after the return
>> >> > either of move/copy must perform .
>>
>> >> Sorry, but you lost me there, what move? Of what to where?
>>
>> > Move ctor of course.
>>
>> Sorry, but I still do not understand. What do you mean with RNVO should
>> be disabled before return but not after? It is something that is
>> performed *during* return.
>
> I mean the whole concept of optimization(rvo,nrvo,etc). IMHO:
> If a function always returns the same local object the returned object
> must be the local object itself

You mean for a function such as

foo bar()
{
foo f;
return f;
}

NRVO should be used? That is (to my knowledge) the case if NRVO is
enabled in the compiler.

> rather than a copy/move version of the local.

What is the difference between copy and move? I would say that NRVO is
move, since the object created in the function is moved to the
"surrounding" context/scope instead of being used as the basis of a copy.

> If a function returns one of its parameter values returned object is
> copy/moved from that parameter because a change in location of the
> object is almost inevitable.

Assuming that you by copy/move mean that the object in the function is
being copied to the surrounding scope, did you mean that something like

foo bar(bool b)
{
foo f1, f2;
if (b)
return f1;
else
return f2;
}

should not use NRVO? Again, to my knowledge that is the case, since the
compiler can not predict which of the objects will be returned so a copy
is necessary.

> If an object is constructed with an rvalue it should be copy/moved.

You mean something similar to

foo bar()
{
foo f1, f2;
return f1 + f2;
}

In that case NRVO could be used depending on whether the compiler knows
which object will be returned or not. So the above could utilise NRVO
but something like

foo bar(bool b)
{
foo f1, f2, f3;
if (b)
return f1 + f2;
else
return f2 + f3;
}

could not.

If the above is not what you meant, then I am sorry to have failed to
understand you. Perhaps you could try to rephrase the question or use
simple code examples.

--
Erik Wikström

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]