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.