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@boostpro.com> 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