Subject: Re: [boost] Is Boost.Range broken?
From: Tomas Puverle (Tomas.Puverle_at_[hidden])
Date: 2008-11-22 13:58:56
> 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.
> Maybe if your iterators are so peculiar and you want to be able to rely
> on that property, you should use something else than iterator_range
> which is designed for all iterators.
Or perhaps you could take the opposite view of saying: "I've never seen usage
like this, but that doesn't make it invalid. Let's see if we can find a way of
making this work." The biggest amount I've learn about programming was through
people who used my libraries in ways I couldn't even imagine.
Anyway, I think a lot of people on this forum are missing the point: I'm not
claiming that the old behaviour is in some way better or worse.
I am saying the following:
1) Is the behavioural change too much of a diversion from previous expected
(documented) functionality that the new change is in fact a defect
2) There are clearly (at least two) distinct classes of problem and I think
they can both be solved. We don't need to shove a square peg into a round hole
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk