- Boost - lists.preview.boost.org

[serialization] Massive failures in develop?
by John Maddock 18 Oct '15

18 Oct '15

Local testing seems to have badly failed: http://www.boost.org/development/tests/develop/developer/serialization.html I've only looked at the msvc failures, and there's an issue in the iostream class destructor - which is to say after the archive classes have been destructed, the iostream class they were using is left in a non-sane state. Beyond that I haven't been able to get anything sensible out of the debugger (looks like memory corruption actually, but I can't be sure). Any ideas? Thanks, John.

2 6

[thread] Do we can a non backward compatible version with non-blocking futures?
by Vicente J. Botet Escriba 18 Oct '15

18 Oct '15

Hi, in Boost 1.58 I fixed some issues as the result of the async and future<T>:then() was not a blocking future as the documentation described. However the implementation is horrible and I suspect that it is subject to deadlocks. BTW, I added already some fixes on the develop branch. Sometime ago I started in a branch an implementation that don't use blocking futures [1]. Well the implementation is also horrible after making futures non-blocking, but less ;-) The problem is that now I have some issues with the executors :( Anyway, Gor has told me that with the blocking implementation he is unable to define await_suspend (using resumable functions) >It is just if .then returns a blocking future, I cannot subscribe a callback to .then in await_suspend. >await_suspend(f, cb) { > f.then(cb); >} &will block here preventing coroutine from suspending I don't know yet if he will reach to configure boost::future<T> on the non-blocking branch. My question is if the Boost community will accept (or even wants) a breaking change on a near release (when I would reach to fix the executors issues) including non-blocking futures instead of the current blocking futures. Best, Vicente [1] https://github.com/boostorg/thread/tree/feature/non_blocking_futures

3 13

[intrusive]: determine the hook type of intrusive::list<>?
by Oliver Kowalke 18 Oct '15

18 Oct '15

I'd like to determine the hook type of an intrusive container (intrusive::list): template< typename List > void do_link( List & lst) { static_assert(std::is_same< typename List::???, my_hook_type >::value); lst.push_back( * this); } In the documentation I didn't found a hint. Oliver

1 0

[regression] New runners for old compilers MSVC-7.1 and GCC 3.4
by Ion Gaztañaga 17 Oct '15

17 Oct '15

Hi, The last compiler update two years ago in Boost 1.55 left MSVC-7.1 and GCC 3.3 as two of the oldest supported compilers: http://www.boost.org/users/history/version_1_55_0.html I have no access to GCC 3.3 but managed to get a Mingw-based GCC 3.4. I will run regressions for for both mingw-GCC-3.4 and msvc-7.1 in master and develop branches in case anyone is interested. I plan to maintain support for them in Move, Intrusive, Container and Interprocess until we reach consensus on a new compiler update. Best, Ion

6 6

[python] Merging pull request #25
by Edward Diener 17 Oct '15

17 Oct '15

The PR is necessary so that user's of Python to not see a deprecated warning coming from the updated type_traits whenever they use Boost python. Would the maintainer of Boost Python please take a look at this simple PR so we can get this in the upcoming release. Thanks !

1 0

[Build] Specify compiler on the command line
by Louis Dionne 17 Oct '15

17 Oct '15

Hi, Still attempting to setup Boost.Build for Hana, I find myself unable to specify the compiler to be used by `b2` on the command line. The system compiler is then used by default, which does not work because I need to test on recent compilers. This can be handled by writing a project-config.jam file with the following in it: import feature ; if ! clang in [ feature.values <toolset> ] { using clang : : /path/to/clang ; } However, this is not very script-friendly, and I wonder whether there's a way to specify it on the command-line instead. Regards, Louis

4 6

[iterator][range] Synchronization on 'master'
by Edward Diener 16 Oct '15

16 Oct '15

I have pushed a number of changes to iterator from 'develop' to 'master' for the next release. A series of these changes on 'develop', by Marcel Raad, is an attempt to remove from 'iterator' the use of the deprecated headers 'boost/iterator.hpp' and 'boost/detail/iterator.hpp' in favor of using 'std::iterator' directly instead of 'boost::iterator' and 'std::iterator_traits' and 'std::distance' directly instead of 'boost::detail::iterator_traits' and 'boost::detail::distance'. Essentially these changes mean that any other library using 'iterator' classes would fail if they attempted to refer to 'boost::iterator', 'boost::detail::iterator_traits', or 'boost::detail::distance'. After I had pushed these changes to 'master' I noticed that it broke 'range' on 'master' and reverted these specific pushed commits on iterator 'master'. On 'develop' the 'range' library ( and possibly other libraries using 'iterator' ) had been changed so that it correctly used the 'std::iterator' terminology rather than the deprecated 'boost::iterator' terminology. If we are going to make this change to 'iterator' on 'master' it needs to be co-ordinated with the same set of changes for other libraries which now work with these changes on 'develop'. I noticed quite a few changes for 'range' on 'develop' which have not been pushed to 'master' for the upcoming release. I will assume that the maintainer of 'range' will want to push these changes to 'master' for the upcoming release so this is a heads up that the changes ( actually the last 'develop' commit for 'range' ) need to be co-ordinated with 'iterator' if it is done. Similarly if any other library depending on 'iterator' needs these changes on 'master' it needs to be co-ordinated with 'iterator'. I will NOT be re-pushing these changes on 'iterator' until this co-ordination is in place as I do not want to break 'master' in the interim. I am also fine with waiting until after this upcoming release to re-push these 'iterator' change to 'master' if that is what is desired by others, but any library currently depending on these changes in 'develop' must be aware of what the decision end up to be.

5 9

[serialization] Test runners being stopped
by Tom Kent 16 Oct '15

16 Oct '15

I think there is a bug in the serialization library that is breaking out of the test harness and causing window's error handling to kick in (when running on Windows, obviously). Usually when this happens the test runner application eventually (I believe) times out the test and marks it as failed. However, there are an incredible number of failures happening (since late last week) and they are bogging down the entire test run. Most of the runs I have attempted in the last week on windows have failed...the ones that have succeeded have taken ~12hrs up from the normal 3-4hrs. I was able to capture a stack trace of one of these random failures: msvcp140d.dll!00007ff9cfffb968() Unknown msvcp140d.dll!00007ff9cff73005() Unknown > test_list_ptrs_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::_Endwrite() Line 649 C++ test_list_ptrs_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::close() Line 341 C++ test_list_ptrs_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::~basic_filebuf<wchar_t,std::char_traits<wchar_t> >() Line 155 C++ test_list_ptrs_text_warchive.exe!std::basic_ofstream<wchar_t,std::char_traits<wchar_t> >::~basic_ofstream<wchar_t,std::char_traits<wchar_t> >() Line 1068 C++ test_list_ptrs_text_warchive.exe!std::basic_ofstream<wchar_t,std::char_traits<wchar_t> >::`vbase destructor'() C++ test_list_ptrs_text_warchive.exe!test_list() Line 65 C++ test_list_ptrs_text_warchive.exe!test_main(int __formal, char * * __formal) Line 176 C++ test_list_ptrs_text_warchive.exe!main(int argc, char * * argv) Line 203 C++ [External Code] I'd be happy to help get to the bottom of this, if you can give me any more diagnostic steps to take. We need to resolve this ASAP because it is preventing the windows test runners from producing timely results and we have a release coming up. Thanks, Tom

2 3

[test] BOOST_PP_VARIADICS is defined twice
by Andrey Semashev 16 Oct '15

16 Oct '15

Hi, For some reason Boost.Test defines the BOOST_PP_VARIADICS macro, which, I believe, is a macro defined by Boost.Preprocessor. This results in build errors as can be seen here: http://www.boost.org/development/tests/develop/developer/output/teeks99-01b… I think Boost.Test should not define BOOST_PP_VARIADICS and rely on Boost.PP for that. In any case, BOOST_PP* is not the namespace of Boost.Test.

2 4

[fusion] result_of_with_decltype is missing
by Andrey Semashev 16 Oct '15

16 Oct '15

Hi, I can see many of my tests are failing like this: http://www.boost.org/development/tests/develop/developer/output/teeks99-01b… Basically, it complains that fusion::detail::result_of_with_decltype is missing and indeed I cannot find it defined in Boost.Fusion anywhere.

1 0