Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: David Abrahams (dave_at_[hidden])
Date: 2008-11-23 02:45:47

on Sat Nov 22 2008, Tomas Puverle <Tomas.Puverle-AT-morganstanley.com> wrote:

>> The library may indeed have been poorly documented, but I don't see how
>> what you wrote here addresses Scott's statement in any way.  You simply
>> cannot count on undocumented behaviors of a library; they are subject to
>> change without notice.
>
> The behaviour WAS documented, as I've stated in a different thread:  It's right
> there at the top of the iterator_range class if the pre 1.35 docs.

Agreed, now that I've seen your quote.

> However, I have to say I don't like what you're doing - I feel like you're
> trying to prove that what we're doing is actually wrong in some way.  

I'm sorry you feel that way.  I don't intend that at all.

> We're looking for a solution to real problem.

Agreed.

> Forget for a second about whether it or it documented.  The question
> is - what can be done?

Agreed again.  However, whether it was documented or not has a huge
effect on my opinion about what can be done.

>> > at the top of iterator_range we see:
>> >
>> > /*! \file
>> >    Defines the \c iterator_class and related functions.
>> >    \c iterator_range is a simple wrapper of iterator pair idiom. 
>> > It provides
>> >    a rich subset of Container interface.
>> > */
>> >
>> > This implies to me that range is trying to look and feel like a container 
>> > - 
>> > not like an iterator.  
>> 
>> I understand that you drew that conclusion, but IMO it's a huge stretch
>> to claim that a concept that doesn't even exist for containers
>> (singularity) should behave in some container-like way for ranges.
>
> Remember that our problem is not with is_singular(), 

A lot of arguments have been flying around this thread, some about
is_singular and others about the fundamental nature of the Range
concept.  I understand those are not *your* concern.

> it is with empty().  is_singular() is just an implementatin artifact.
> The behaviour we care about is whether or not a default constructed
> iterator_range should be empty(), in line with standard containers.

Understood.

>> > I agree that singular iterators (as defined in the standard) are
>> > undefined when default constructed; 
>> 
>> To be precise, they're not undefined.  All singular iterators are alike,
>> regardless of how they're produced (default-constructed or otherwise).
>> They have two defined operations: assignment and destruction.
>
> But not all default constucted iterators are singular.

True, but in generic code (e.g. inside of iterator_range), in the
absence of any further information, you have to treat them that way.

>> You're free to define models of Range that have a default-constructed
>> empty state.  Requiring all models of Range to behave that way is
>> antithetical to the principles of generic programming.
>
> We certainly agree on this.  We're not proposing that we have a single
> iterator_range class that fits all purposes, again as I've stated in
> several posts.

I understand that.  Others' arguments seemed to be headed that way.

>> but AFAICT the only thing that a Range has in common with a container
>> is that it supplies a begin() and end() that delimit a sequence of
>> elements.
>
> Actually, the similarity is much stronger than that:
>
>         iterator  begin() const;
>         iterator  end() const;
>         size_type size() const;
>         bool      empty() const;

On the Range concept those are free functions, not members.

> Unfortunately I don't have my standard at hand (it's at work) but IIRC
> all of the are part of the "Container requirements".

Yes, but they're not part of the "Range requirements."  If they were,
pair<int*,int*> couldn't be a Range.

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