Re: [Boost-users] [Range] non-const range reference

Subject: Re: [Boost-users] [Range] non-const range reference
From: Neil Groves (neil_at_[hidden])
Date: 2010-04-23 04:51:38

On Thu, Apr 22, 2010 at 11:43 AM, Robert Jones <robertgbjones_at_[hidden]>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