on Mon Dec 10 2007, "Niels Dekker - mail address until 2008-12-31" <nd_mail_address_valid_until_2008-12-31-AT-xs4all.nl> wrote:
David Abrahams wrote:
I have just committed a fix for this bug to the trunk: http://svn.boost.org/trac/boost/changeset/41942
Unfortunately, as https://boost-consulting.com/trac/projects/boost/build/trunk shows, that appears to have broken Boost.Python on Linux/GCC.
Do you mean the failures at python/test/try.cpp ? I have no clue how those failures could possibly be caused by value_init. Do you?
https://boost-consulting.com/trac/projects/boost/build-details/trunk/795/pyt... says: File "newtest.py", line 7, in __main__ Failed example: from m2 import * Exception raised: Traceback (most recent call last): File "doctest.py", line 1212, in __run compileflags, 1) in test.globs File "<doctest __main__[1]>", line 1, in <module> from m2 import * ImportError: No module named m2 [...]
Nope. And they disappear in the next revision just as mysteriously.
I recently added tests on these issues to value_init_test, and they caused a test failures on a majority of the test platforms, at http://beta.boost.org/development/tests/trunk/developer/utility_.html
I guess maybe that explains the Boost.Python test failures?
Most of the tests that I added to value_init_test actually tested the compiler implementation of value-initialization. (Except for the most recently added test, changeset [41919], which tested copying value_initialized<T> objects.) It's still unclear to me how providing a workaround to those compiler issues could cause Boost.Python test failures...
The good news: the value_init tests at beta.boost.org now have "unexpected" passes for Sandia-gcc-64: http://beta.boost.org/development/tests/trunk/developer/utility_.html I expect other platforms to go green on the value_init test soon... :-)
Nifty :-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com