Re: [boost] [range] iterator_range::operator[] broken

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

> >> 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
> other
> > changes are working well. It would be extremely disappointing to revert
> all
> > 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:
>
>
> http://beta.boost.org/development/tests/release/developer/output/RW_WinXP_VC-boost-bin-v2-libs-accumulators-test-covariance-test-msvc-8-0-debug-iterator_debugging-off-link-static-threading-multi.html
>
> 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
additional features.

> == Volunteers Needed ===
>
> If anybody else is reading this: please look at the regressions on the
> release branch here:
> http://beta.boost.org/development/tests/release/developer/summary.html.
> 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
> http://www.boostpro.com
>

Regards,
Neil Groves