|
Boost : |
Subject: Re: [boost] [iterator] Help needed understanding output_iterator requirements
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2010-05-01 20:50:47
Dear authors of Boost.Iterator,
As described in <http://lists.boost.org/Archives/boost/2010/03/163133.php>, Boost.MultiArray is currently unusable with the recently released MSVC 10. This is also confirmed by many failures in the regression tests: <http://www.boost.org/development/tests/release/developer/multi_array.html>.
These failures are caused by a specific behavior of iterator_facade from Boost.Iterator, introduced by Jeremy Siek with the explanation "changed iterator_facade_default_category to stop lying about output_iterator_tag": <https://svn.boost.org/trac/boost/changeset/21683>.
I'm not the right person to judge (or understand) how serious the original code was a lying, but the attached patch that conditionally reintroduces the original behavior as a workaround for MSVC 10 fixes all compile failures of the regression tests of Boost.MultiArray for me (MSVC 10 does compile time checking of iterator categories when _HAS_ITERATOR_DEBUGGING is defined). However, the "resize" regression test then fails with a runtime error (assertion failure) instead of a compile error:
testing.capture-output ..\..\..\bin.v2\libs\multi_array\test\resize.test\msvc-10.0\debug\threading-multi\resize.run
====== BEGIN OUTPUT ======
Assertion failed: index_bases[n] <= start && start < index_bases[n]+index(extents[n]), file C:\nobackup\boost_trunk\boost/multi_array/base.hpp, line 446
C:\nobackup\boost_trunk\boost/test/minimal.hpp(123): exception "R6010
- abort() has been called
" caught in function: 'int __cdecl main(int,char *[])'
**** Testing aborted.
**** 1 error detected
EXIT STATUS: 201
====== END OUTPUT ======
I have no idea whether this failure is related to the reintroduced lying or not. All I know is that there have been recent request to find "some kind of proper workaround or fix" for these issues: <http://lists.boost.org/Archives/boost/2010/04/165548.php>. But from my point of view, the only responsibility I may have with respect to these issues is to notify the authors of the affected libraries, which I have done now.
Regards,
Thomas
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk