Re: [boost] [utility] value_init workaround fixed [Re:value_init_test failure]

From: Niels Dekker - mail address until 2008-12-31 (nd_mail_address_valid_until_2008-12-31_at_[hidden])
Date: 2007-12-10 05:17:46

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/python/17 
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
[...]

>> 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...  :-)

Kind regards, Niels