Subject: Re: [boost] [range] iterator_range::operator broken
From: Neil Groves (neil_at_[hidden])
Date: 2010-04-14 03:57:53
On Wed, Apr 14, 2010 at 8:42 AM, Eric Niebler <eric_at_[hidden]> wrote:
> Neil, let's keep this discussion on-list. It's important.
> On 4/14/2010 12:21 AM, Neil Groves wrote:
> It is a breaking interface change in a core library. What is the
> technical reason for it?
A trac issue was raised regarding iterator_range handling of iterators that
return proxies. The change was motivated by attempting to resolve the trac
issue. Since this specific solution is worse than the original problem I
have altered the iterator_range code and reverter the operator handling to
the old behaviour.
The other change to the core functionality is being more permissive with
respect to potentially singular iterators. This change I have kept in
> >> Neil?
> > I need to take another look at the code and perhaps the operator of
> > iterator_range is broken, but I believe that this issue aside that the
> > changes are working well. It would be extremely disappointing to revert
> > of the adaptors, and algorithms just because of this issue. I'm more than
> > happy to fix the problem as soon as I can.
> I'm seeing massive breakages all over trunk and release, not all of
> which are related to the changed return type of
> iterator_range::operator. For instance, there seems to be some new
> ambiguity in the "detail" symbol. See for instance:
> I can't be certain at this point if RangeEx is responsible, but it's
> where I would start looking. Could you have a look and report back?
I have previously looked over the 'broken' regression tests and did not see
a connection to the Boost.Range changes. I will look deeper into the
outstanding problems over the other libraries.
I can look at the issue tonight. I'm sure that even if this is an issue with
Boost.Range that it is easily remedied. I had not spotted the connection
between Boost.Range and the accumulators regression failure. Do you have
other examples where the updates to Boost.Range are the cause of the
problems? I suspect that any issues will be minor and easily resolved since
the header file separation means that old code is largely unaffected by the
> == Volunteers Needed ===
> If anybody else is reading this: please look at the regressions on the
> release branch here:
> Pick a broken library that interests you and figure out why it's busted.
> Report back.
If volunteers spot issues that are related to Boost.Range changes I am very
keen to hear back so that I can improve the backward compatibility.
> Eric Niebler
> BoostPro Computing
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk