On Wed, Apr 14, 2010 at 8:42 AM, Eric Niebler <eric@boostpro.com> 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...
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