Boost logo

Boost :

Subject: Re: [boost] Is Boost.Range broken?
From: Tomas Puverle (Tomas.Puverle_at_[hidden])
Date: 2008-11-22 14:39:35

> 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.

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. We're
looking for a solution to real problem. Forget for a second about whether it
or it documented. The question is - what can be done?

> I doubt I'll find quotes from the source very persuasive, since what you
> can count on should be determined by the docs.... of course comments in
> the source are a kind of documentation.

Dave was just demonstrating why the is_singular() function is broken.

> > 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(), 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. The comment from the source was Dave's
example of why it wasn't unreasonable to assume such behaviour.

> > 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.

> Perhaps. But did the documentation guarantee that it would work?

Yes - please see the old docs or my previous posts.

> 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

> 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;

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

> I would find that argument more compelling if there was a "singular"
> concept that applied to containers, but there isn't.

We don't care about the singular concept. We only care about the default
constructed/empty() concept.


Boost list run by bdawes at, gregod at, cpdaniel at, john at