From: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>

To: boost@lists.boost.org

Subject: Re: [boost] [Boost.Move] [Boost.Container] Compiling with

older versions of Boost and Performance

Message-ID: <4F09F0C3.4080306@wanadoo.fr>

Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Ø Le 08/01/12 12:25, Thomas Jordan a ?crit : Ø >> Message: 3 Ø >> Date: Sat, 07 Jan 2012 15:58:20 +0100 Ø >> From: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> Ø <snip> Ø >> Le 07/01/12 12:10, Thomas Jordan a ?crit : Ø >>> Hi, Ø >>> I am interested in experimenting with v1.48 Boost.Move and Ø >>> Boost.Container. However, I am otherwise constrained to using Boost Ø >>> libraries v1.33.1 with Ø >>> a Sun C++ v5.10 compiler. I couldn't seem any 'Boost library Ø >>> dependencies' listed in the Move/Container documentation, but a Ø >>> quick look through the header files suggests Ø >>> that it is mainly MPL and Type Traits. So... Ø >>> First question: would it be feasible for me to combine the headers Ø >>> for these two libraries with the v1.33.1 libraries and get it to Ø >>> work (albeit maybe with a little customisation), or would it be a Ø >>> big job/non-starter? Ø >>> Second question - I don't see any performance analysis published for Ø >>> Boost.Move. I know that move semantics is about more than improved Ø >>> performance, but am interested in that side of things, especially as Ø >>> the above compiler appears suboptimal in terms of copy elision and Ø >>> RVO. I am wondering for example whether are there any Ø >>> (compiler-specific) factors which could mitigate against the Ø >>> performance benefits of doing a move vs a copy of a vector, using Ø >>> these libraries, for example. Ø >>> Ø >> Ø >> Hi, Ø >> Ø >> unfortunately Boost.Move and Boost.Container are not working up to now Ø >> on Sun c++ even on trunk (1.49). See Ø >> http://www.boost.org/development/tests/trunk/developer/container.html. Ø >> Ø >> Best, Ø >> Vicente Ø Ø >Thanks for pointing me to that. In general is there anything more Ø >detailed than pass/fail available to look at? Ø >Is the assumption that something with so many fails it not fixable one Ø >the library side, and is not worth investigating? Ø > Ø > Ø Lastly there were some issues reporting the failure on the Sandia Ø testers. Sun compiler miss a lot of useful features for many Boost Ø libraries. Ø I think the best you can do is to install the version 1.48 (or the Ø trunk), run the tests yourself, look for the first failures in Ø Boost.Move and try to understand what is going wrong. Report the Ø failures here and try to solve them with the help of Ion and the Boost Ø comunity. Ø HTH, Ø Vicente 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? Regards, T.