Re: Nested function call and RVO.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Lawrence,

Thanks a lot for your clarification on this issue.

Right now I don't have figures to evaluate any performance boost,
tough at first it could be said that the nesting could be
(arbitrarily) deeper and so some more objects would be created, say,
unnecessarily.

Thanks a lot again.

--
Rodolfo Federico Gamarra

PS: The operator = lacks a proper return statement (e.g. return
*this;), sorry about that.


On Mon, Dec 7, 2009 at 20:15, Lawrence Crowl <crowl@xxxxxxxxxx> wrote:
> On 12/7/09, Rodolfo Federico Gamarra <rgamarra@xxxxxxxxx> wrote:
>> Hi all,
>>
>> I have been reviewing the RVO optimization technique and came across
>> with a nested function call where I hoped this optmization to work as
>> well.
>> I compiled the following snippet with
>> g++ -O3     main.cc   -o main
>> and got as result
>> A()
>> N()
>> A(A&)
>>
>> Is there any fundamental reason for this optimization not to happen in
>> this case? I was hoping to get only one object constructed at all. The
>> relevant passage in the standard seems to me is "12.8 - Copying class
>> objects (15)".
>> // main.cc
>> #include <iostream>
>> using namespace std;
>> struct A {
>>   A()                       { cout << "A()\n";                  }
>>   A(const A& a)             { cout << "A(const A&)\n";          }
>>   A(A& a)                   { cout << "A(A&)\n";                }
>>   A& operator=(const A& a)  { cout << "operator=(const A&)\n";  }
>>   void N()                  { cout << "N()\n";                  }
>> };
>> A   AlternativeA(A a)       { a.N(); return a;                  }
>> A   FactoryA()              { return A();                       }
>> int main()                  { A a = AlternativeA(FactoryA());   }
>> //eof
>>
>> Thanks a lot for your help in advance.
>
> The function AlternativeA does not construct "a", and hence one
> could argue that RVO does not apply.  Conversely, one could argue
> that the standard's rule doesn't talk about function boundaries wrt
> the construction of the automatic object, and hence RVO does apply.
> That latter interpretation is somewhat inconsistent with the
> structure of compilers, and of GCC in particular, because inlining
> happens after RVO.
>
> To change the current behavior, you would need a convincing case
> that the performance benefit is significant.
>
> --
> Lawrence Crowl
>


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux