Re: [boost] [Range] breaking update pending

From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2006-01-31 09:44:24

David Abrahams wrote:

 > MB <mb2act_at_[hidden]> writes:
 >
 >
 >> Thorsten Ottosen wrote:
 >>
 >>> Dear All,
 >>>
 >>> I have been trimming boost.range to incorporate the changes we have 
been
 >>> discussing some time ago.
 >>>
 >>> These changes will break many uses of the library. Inside boost 
this will affect
 >>>
 >>> Boost.foreach
 >>> Boost.string algo
 >>> Boost.iostreams (*)
 >>>
 >>> (*) I don't this will break
 >>>
 >>> The list of major changes is the follwing:
 >>>
 >>> 1. ADL hooks renamed boost_range_begin -> range_begin,
 >>>                      boost_range_end -> range_end
 >>
 >>
 >> Why was such short name accepted??
 >> Even 'const_begin' that calls unqualified 'begin' breaks down 
Boost.MPL!!

This was a bug. In the new version there is no unqualified
call to begin(), end(), size() and empty().

 >
 > How so?  What happens?  Got a small reproducible case?
 >

GCC ADL looks up a class named "end" too. Old story.

 >>> 2. ADL hook boost_range_size removed; boost::size(rng) now requires
 >>>    RandomAccessIterators to guarantee O(1) complexity.
 >>>
 >>> 3. range_result_iterator renamed range_iterator and range_iterator 
renamed mutable_iterator. The correct way to spell const_iterator<T> is 
now iterator<const T>.
 >>
 >>
 >> range_result_iterator is alive? If so, it's nice. :-)

It's dead, sort of, or that was the intention. It's behavior is now
modelled by range_iterator.

 >>> 4. intrinsic string support removed. instead a header 
as_literal.hpp is previded with a small utility for use in string 
algorithms.
 >>
 >>
 >> FWIW, I experienced "Range adaptor syntax" could make it prettier.
 >
 >
 >
 > Thorsten, did you consider providing a backward compatibility layer
 > for the transition?

Yes, but I don't have a good way to do this. putting the old version in, 
say, boost/range/v1 was rejected because of ODR problems.

Do you have any ideas?

-Thorsten