Thomas Klimpel wrote:

THOMAS JORDAN wrote:

...

Thanks, yes that would be the sensible way to proceed.

...

My other question was, though -

...

Does Boost::Move library rely on compiler optimisations of

...

copy-elision/return value optimisation, as is the case with the Adobe

...

Source Library (ASL) Move library, for example. The reason I ask is

...

that I suspect the compiler I want to target is not very good at

...

said optimisations. Or are there any other known factors which

...

could

...

mitigate

...

against its effectiveness for a. n. other compiler?

Note the RVO (return value optimization) is a feature that is either working

or not, similarly to tail recursion in functional languages. This is unlike

URVO (unnamed return value optimization), which depends on the code

analysis capabilities of a optimizer. (Well, some compilers used to turn off

RVO in debug mode, but this should no longer be the case.)

Writing tests to check whether RVO is implemented is easy. I guess you

have a pretty good chance that even your compiler supports RVO (so I

guess the ASL Move library would work). But this doesn't mean that it will

be easy to get Boost.Move working with your compiler.

Actually, just to clarify, I ran some tests which indicate the compiler (Sun C++ 5.10) does RVO on temporaries, but does not do NRVO and also does not seem to do copy-elision (as often as it might, at least). Now the ASL Move library does definitely depend on copy elision to provide any performance benefit, as is stated in its documentation. I tried that library and saw no gain - exactly the same call sequence took place. That seems to make sense I have pulled in the Boost::Move library - actually I only just pulled/hacked in the bare minimum, i.e., the macros and the ::boost::rv class and little else, as I am not so concerned about the C++0x/C++03/platform portability to begin with, just the performance. I got it compiling and running just before I knocked off for the day. It looks like there may be a couple fewer copies than with ASL or than without any move library, but not as much of a reduction as I wanted/expected, though I need to analyse it again more thoroughly tomorrow. It looks from the design of the boost::rv classes and associated overloads, and the conversion operators generated like the macros, that unlike ASL, Boost::Move doesn't rely on RVO/NRVO/copy elision in order to perform. Is that a reasonable assumption? Or is there anything else that people are aware of which could hinder the optimal performance of Boost::Move? Regards, T.