Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: David Abrahams (dave_at_[hidden])
Date: 2008-11-28 16:22:09

on Tue Nov 25 2008, "Scott McMurray" <me22.ca+boost-AT-gmail.com> wrote:

> On Tue, Nov 25, 2008 at 13:31, David Abrahams <dave_at_[hidden]> wrote:
>>
>> on Mon Nov 24 2008, "Tomas Puverle" <Tomas.Puverle-AT-morganstanley.com> wrote:
>>
>>>> There's no reason that they both have to be in boost. Boost range
>>>> should let you use your own range class.
>>>
>>> And you're absolutely right.  Having said that, it's not inconceivable that
>>> others may have been relying on the same behavour.
>>> That's one of the things this discussion was about.
>>
>> Yes.  The library maintainer ought to do something to help those people,
>> by providing the old behavior in code somewhere (even if that code only
>> appears in docs).
>>
>
> How about providing code something like this (thanks to Boost.Iterator):
>
>     template <class Iter>
>     class nonsingular_default
>       : public boost::iterator_adaptor<
>             node_iter<Value>                // Derived
>           , Iter                            // Base
>         >
>     {
>      private:
>         bool is_default_constructed;

<schnipp>

>     };
>
> Allowing recovery of the old semantics using
>
>     iterator_range< nonsingular_default<I> >
>
> (at least for Tomas Puverle's use case.)

Now, unless you specialize iterator_range for nonsingular_default<T>,
you are paying for two booleans where previously you only needed one.

However, I like the general approach, which allows the interface to
iterator_range to remain relatively uncorrupted.  In other words,
something like this would work:

  template <class I>
  struct nonsingular_default
  {};

  template <class I>
  struct iterator_range<nonsingular_default<I> >
  {
     // implementation of old iterator_range semantics

   private:
     I start, finish;
  };

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com