[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

mojo and return value optimization

Peng Yu

10/21/2008 8:31:00 PM

Hi,

On http://www.ddj.com/database..., it says

"...the goal is portable efficiency — 100% elimination of unnecessary
copies, without dependence on one particular RVO implementation."

But if there is RVO in the compiler that I'm using (I think GCC has
it, right?) and I do not care about other compiler, do I still need
the technique mentioned on that webpage?

Thanks,
Peng
5 Answers

Hendrik Schober

10/21/2008 10:16:00 PM

0

Peng Yu wrote:
> Hi,
>
> On http://www.ddj.com/database..., it says
>
> "...the goal is portable efficiency ? 100% elimination of unnecessary
> copies, without dependence on one particular RVO implementation."
>
> But if there is RVO in the compiler that I'm using (I think GCC has
> it, right?) and I do not care about other compiler, do I still need
> the technique mentioned on that webpage?

That depends on whether your compiler can actually apply
RVO in your specific case and how much you depend on that
being the case.

> Thanks,
> Peng

Schobi

Peng Yu

10/21/2008 11:10:00 PM

0

On Oct 21, 5:16 pm, Hendrik Schober <spamt...@gmx.de> wrote:
> Peng Yu wrote:
> > Hi,
>
> > Onhttp://www.ddj.com/database..., it says
>
> > "...the goal is portable efficiency — 100% elimination of unnecessary
> > copies, without dependence on one particular RVO implementation."
>
> > But if there is RVO in the compiler that I'm using (I think GCC has
> > it, right?) and I do not care about other compiler, do I still need
> > the technique mentioned on that webpage?
>
> That depends on whether your compiler can actually apply
> RVO in your specific case and how much you depend on that
> being the case.

Do you have a summary on how many cases could be for RVO? If I know
all the cases, then I can make a sound decision on what I should for
each case?

Do you know how different many commonly used compilers are in the
aspect of RVO?

Thanks,
Peng

Triple-DES

10/22/2008 8:11:00 AM

0

On 21 Okt, 22:30, Peng Yu <PengYu...@gmail.com> wrote:
> Hi,
>
> Onhttp://www.ddj.com/database..., it says
>
> "...the goal is portable efficiency — 100% elimination of unnecessary
> copies, without dependence on one particular RVO implementation."
>
> But if there is RVO in the compiler that I'm using (I think GCC has
> it, right?) and I do not care about other compiler, do I still need
> the technique mentioned on that webpage?
>

If you are using gcc 4.3, and do not care about portability, you can
use rvalue references to implement move construction and move
assignment. It's the same principle, but with direct language
support.

> Thanks,
> Peng

ytrembla

10/22/2008 8:56:00 AM

0

In article <c516fd50-e2f2-45a7-999a-88cbd81777ac@l77g2000hse.googlegroups.com>,
Peng Yu <PengYu.UT@gmail.com> wrote:
>On Oct 21, 5:16 pm, Hendrik Schober <spamt...@gmx.de> wrote:
>> Peng Yu wrote:
>> > Hi,
>>
>> > Onhttp://www.ddj.com/database..., it says
>>
>> > "...the goal is portable efficiency ? 100% elimination of unnecessary
>> > copies, without dependence on one particular RVO implementation."
>>
>> > But if there is RVO in the compiler that I'm using (I think GCC has
>> > it, right?) and I do not care about other compiler, do I still need
>> > the technique mentioned on that webpage?
>>
>> That depends on whether your compiler can actually apply
>> RVO in your specific case and how much you depend on that
>> being the case.
>
>Do you have a summary on how many cases could be for RVO? If I know
>all the cases, then I can make a sound decision on what I should for
>each case?

In which situation RVO does apply or not is not what is important.
What is important is what part of your code is causing an *actual*
performance bottleneck.

I generally like Alexandrescu's writings but this one IMO is a case of
code obfuscation in search of performance. This is all fine if
performance is needed but IMO in the general case, development speed,
maintainability and quality are far more important. If it is
necessary because you are in the presence of a measured performance
bottleneck, then by all mean, go for it. In the general case, I don't
think so.

Yannick

Hendrik Schober

10/22/2008 9:32:00 AM

0

Peng Yu wrote:
> On Oct 21, 5:16 pm, Hendrik Schober <spamt...@gmx.de> wrote:
>> Peng Yu wrote:
>>> Hi,
>>> Onhttp://www.ddj.com/database..., it says
>>> "...the goal is portable efficiency ? 100% elimination of unnecessary
>>> copies, without dependence on one particular RVO implementation."
>>> But if there is RVO in the compiler that I'm using (I think GCC has
>>> it, right?) and I do not care about other compiler, do I still need
>>> the technique mentioned on that webpage?
>> That depends on whether your compiler can actually apply
>> RVO in your specific case and how much you depend on that
>> being the case.
>
> Do you have a summary on how many cases could be for RVO? If I know
> all the cases, then I can make a sound decision on what I should for
> each case?
>
> Do you know how different many commonly used compilers are in the
> aspect of RVO?

No. This is all compiler-dependent. You have to know the innards
of your compiler to know ahead for sure. If you lack that, you'll
just have to try.

> Peng

Schobi