What you are looking for is a reversing adaptor, hence you probably
should look at boost::adaptors::reversed, please see
http://www.boost.org/doc/libs/1_46_1/libs/range/doc/html/range/reference/adaptors/reference/reversed.html.

No, the reversing adaptor doesn't work either. Remember I want to specify *at compile time* whether or not to reverse the range.


Not only does the reverse adaptor work it can easily address your stated problem.Like this:

template<typename RangeT, typename Cond>
struct conditional_reverse_type_generator
{
    typedef typename boost::mpl::if_<
        Cond,
        boost::reversed_range<RangeT>,
        boost::sub_range<RangeT>
    >::type type;
};

template<typename Cond, typename RangeT>
inline
typename conditional_reverse_type_generator<RangeT,Cond>::type
conditional_reverse(RangeT& rng)
{
    typedef typename conditional_reverse_type_generator<RangeT,Cond>::type result_type;
    return result_type(rng);
}

template<typename Cond, typename RangeT>
inline
typename conditional_reverse_type_generator<const RangeT,Cond>::type
conditional_reverse(const RangeT& rng)
{
    typedef typename conditional_reverse_type_generator<const RangeT,Cond>::type result_type;
    return result_type(rng);
}


 
If hypothetically there was a "null" range adapter, I could do something like:

typedef boost::mpl::if_<Reversed,
   boost::adaptors::reversed,
   boost::adaptors::null>::type adaptor;

boost::copy( adaptor(range) , ...);

But that doesn't seem to exist either.


I have never had the need for a null adaptor, and this would be the first request. I shall implement one for a later version of Boost since I can see a few use cases. However you need not wait, and I don't think it provides a better solution to your problem.
 

Note that you could also use the reversed_range class directly.


It is implemented in a detail namespace, but is brought into the boost namespace. This changed from the first versions of Boost.Range with adaptors. By popular demand the return types of the adaptors are now all public documented types.
 
I make a point of never using anything in a detail namespace unless absolutely necessary. But even in this case I don't think it will help.

You don't need to use anything in a detail namespace, and it does help ;-)
 
Regards,
Neil Groves