On Thu, Apr 22, 2010 at 11:43 AM, Robert Jones <robertgbjones@gmail.com> wrote:

I'm not able to use the latest Boost release, so I've plagarised some little
bits that are useful, and in the process might have missed something, so
bear with me.

I have this bit of code...

#include <algorithm>
#include <boost/range.hpp>

template < class SinglePassRange, class UnaryFunction >
    UnaryFunction for_each( SinglePassRange & rng, UnaryFunction fun )
{
    return std::for_each( boost::begin( rng ), boost::end( rng ), fun );
}

struct A { };
void f( const A & );

std::vector< A > generateVec( );

int main( )
{
    for_each( generateVec( ), f );
}

which understandably fails to compile as I'm passing an lvalue as non-const
reference. I can fix this by adding a const ref overload of for_each, but no such
overload exists in the real boost range header (AFAIK).

Gosh this was unfortunate. The lack of a const overload existed only on the trunk (never the release branch) for a few days.

This could not have been more wrong if I coloured it purple! You should indeed match the current trunk and the release branch by adding a const overload for_each.

Returning containers by value seems to be the 'right way' now, as RVO should
sort out the copy elision.

I'm not convinced that this is the 'right way'. I find that for trivial examples the copy is optimized away, but that on many compilers at various levels of call depth the copy construction occurs causing a huge performance degradation. I suspect that the 'right way' is still by using references in C++03 and by using move constructors in C++0x.

What I'm doing in this code seems reasonable - should it be supported by
const ref overloads, or have I missed some 'gotcha' somewhere?

You are not missing anything at all. The const overload should be there and will always be there in Boost.Range.

Thanks,

- Rob.

Sorry for any confusion and wasted time,

Neil Groves