Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2008-11-25 22:46:29

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;

     public:
        node_iter()
          : node_iter::iterator_adaptor_(),
            is_default_constructed(true) {}

        explicit node_iter(Iter i)
          : node_iter::iterator_adaptor_(i),
            is_default_constructed(false) {}

     private:
        friend class boost::iterator_core_access;
        bool equal(nonsingular_default i) {
            if (is_default_constructed && i.is_default_constructed) {
                return true;
            }
            if (!is_default_constructed && !i.is_default_constructed) {
                return base == i.base();
            }
            return false;
        }
    };

Allowing recovery of the old semantics using

    iterator_range< nonsingular_default<I> >

(at least for Tomas Puverle's use case.)

This, of course, depends on the asserts getting removed, but that
behaviour is also replicable using the same technique.