Boost logo

Boost :

Subject: Re: [boost] Is Boost.Range broken?
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2008-11-23 07:53:47

Daniel Walker skrev:
> Please cite who you're quoting. See the discussion policy at
> On Sat, Nov 22, 2008 at 1:58 PM, Tomas Puverle
> <Tomas.Puverle_at_[hidden]> wrote:
>>> However, that is certainly not guaranteed by the iterator concepts.
>>> Therefore, when you deal with iterators in a generic way, you should not
>>> assume such a thing.
>> And we're not.
>>> iterator_range being a generic tool, it wants to maintain the invariants
>>> which are necessary to make it work whatever its parameters are, even if
>>> those invariants happen not to be necessary for some parameters.
>> But as a "generic" tool, iterator_range is now assuming too much and breaking
>> existing code. Also, currently iterator_range is close to me wanting to say
>> that it doesn't really maintain any invariants, IMHO.
> I was about to suggest that if you want to build a generic library
> that uses ranges, stick to the Range concepts
> ( and avoid tying yourself to types
> generated from iterator_range. Tight bundling always causes problems
> like this. With concepts all of the constraints on a type can be
> encoded in a concept checking class and automatically verified at
> compile time (and of course proposed C++0x language extensions could
> make this even easer/cleaner). Users can rely on the concepts being
> implemented, and authors can use concept checks to make sure their
> implementations meet user expectations.
> Unfortunately, the Range concept checks appear to have been changed
> about a year ago, apparently in response to the changes in
> iterator_range. As far as I can tell from looking at the svn history,
> when iterator_range failed to meet the Range concepts, rather than
> changing iterator_range,

Is an iterator_range not a range? I don't recall anything like this. Was
I the one that changed the test?


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