Re: [boost] [Range] breaking update pending

From: MB (mb2act_at_[hidden])
Date: 2006-01-31 19:29:02

Thorsten Ottosen wrote:
> 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.

You mean all the customization way is deprecated?

>  >>> 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?

Ideally, Boost.Range v2 is needed, which has all the range-style algorithms,
all the range adaptors, class-template-based customization using tag-dispatching,
supports also ADL customization, can play with Boost.IOStreams,
and throws away legacy compilers! :-)

   range::copy(file_rng|range::filtered(is_even()), out);
   result_of<range::begin_function(int[10])>::type first = range::begin(array);

I already find Boost.Sequence. :-)

Regards,
MB