- Boost - lists.boost.org

[1.55b1][coroutine][exception] not propagating exception type
by Jeff Flinn 29 Oct '13

29 Oct '13

I'm on VS2013, with BOOST_COROUTINES_V1 defined. I've merged boost::coroutine's exception test with boost::exception's derives_std_exception test. A std::exception& is caught when based on docs I would expect derives_std_exception to be caught. Am I doing something obviously wrong? Thanks, Jeff #include <boost/coroutine/all.hpp> #include <boost/bind.hpp> struct derives_std_exception : std::exception {}; namespace coro = boost::coroutines; typedef coro::coroutine< void() > coro_void_void; template< typename E > void f14(coro_void_void::caller_type & , E const& e) { throw e; } int main() { try { coro_void_void coro( boost::bind(f14< derives_std_exception > , _1, derives_std_exception())); return -1; } catch (derives_std_exception const&) { return 0; } catch (std::exception const&) { return -1; } catch (...) { return -1; } }

3 4

Introduction and Cray support. [config] [build] [atomic] [interprocess] [asio] [dump] [tr1]
by Richard Dale 29 Oct '13

29 Oct '13

Hello world, My name is Richard Dale. I work at Cray, Inc. My purpose here is to get the boost libraries and Cray C++ compiler to work and play together better. I have a couple of questions, but maybe some background first. The first thing I plan to do is fix up the existing config/compiler/cray.hpp and .../v2/tools/cray.jam files. With this done, both the static and dynamic versions of most buildable libraries build successfully. The second thing is to address cray specific issues in the libraries listed in the subject line. With the exception of tr1, these are all preprocessor changes to avoid inline assembly, which the cray C++ compiler does not support yet, and probably won't anytime soon. The tr1 change is to provide a Cray version of the macro BOOST_TR1_STD_HEADER_NAME. The third thing will be to "officialize" the cray compiler, so that it gets picked up and used by default when it is the default compiler on Cray systems. The target is to provide good support for Cray C++ in the 1.56 release. Once the configuration changes are done, we (Cray) will start running the regression tests on a regular basis. I'm a little uncertain as to how to proceed in the immediate term, especially given the impending conversion to git. The idea of compiler support is somewhat orthogonal to the notion of library support, and there doesn't seem to be a well defined concept of compiler owner. I seem to have couple of options. The first option would be to get as much done as possible pre-conversion. My assumption is that I would check everything into the trunk, (The library changes are pretty trivial), using Trac tickets to keep the library owners in the loop. I assume it is the individual library owners who take care of the merges from trunk to branches/release (master?), although I'm unsure where this falls on the continuum between ordinarily true and always true. The second option would be to wait until the cutover to git, and do the workflow for making changes to a library owned by someone else. This is probably the right thing, but I'm more fluent with svn than with git. So, I guess I'm looking for advice and consent here. Please straighten me out if there is something I seem not to understand. For what it's worth, I've made myself "champion" for the Cray compiler. I don't pretend to know everything, but if I can't figure something out, I probably know who to ask. I'll take any Trac tickets relating to Boost on Cray. Regards, Richard

3 2

[1.55] Request permission to merge 84402
by Jürgen Hunold 29 Oct '13

29 Oct '13

Hi! I would like to merge 84402 to release. I missed the deadline due to provider hardware problems killing my DSL. ------------------------------------------------------------------------ r84402 | jhunold | 2013-05-21 14:23:20 +0200 (Di, 21 Mai 2013) | 4 lines Fix: cache file loading and saving must use native paths Fixes caching at least on Windows platform ------------------------------------------------------------------------ Building Boost and using Boost.Build without this fix works, but the caching system is rendered useless at least on Windows. The cache files simply can't be written. Seems this already missed 1.54. Tested on trunk with msvc and gcc. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 2

[release] permission to merge Stephan's bootstrap changes?
by Eric Niebler 29 Oct '13

29 Oct '13

I've manually verified Stephan's fix. May I merge https://svn.boost.org/trac/boost/changeset/86460 and end Stephan's suffering? See the extensive thread beginning at http://lists.boost.org/Archives/boost/2013/10/207525.php for the complete discussion (or as much of it as lists.boost.org currently has archived). -- Eric Niebler Boost.org http://www.boost.org

3 3

[1.55] Request permission to merge 84443
by Beman Dawes 29 Oct '13

29 Oct '13

I just finished merging and testing locally. Lack of 84443 was causing both MSVC 2012 and 2013 to fail iterator_adaptor_test (and many other tests in many other libraries). After the merge, iterator_adaptor_test passes for both compilers. Request permission to merge. Andrey Semashev reports: > The problem has already been mentioned several times on the maling lists > and the bug tracker: > > https://svn.boost.org/trac/boost/ticket/9205 > > https://svn.boost.org/trac/boost/ticket/9249 > > https://svn.boost.org/trac/boost/ticket/9278 > > http://thread.gmane.org/gmane.comp.lib.boost.user/79919 > > http://thread.gmane.org/gmane.comp.lib.boost.user/79932 > > http://thread.gmane.org/gmane.comp.lib.boost.devel/244986 > > http://thread.gmane.org/gmane.comp.lib.boost.devel/245596 --Beman

2 2

[1.55][mpl][atomic] Tests failing on MSVC-12
by Andrey Semashev 29 Oct '13

29 Oct '13

Hi, I'm seeing Boost.Atomic test failures on MSVC-12 with the following errors: C:\local\boost\boost/iterator/detail/facade_iterator_category.hpp(166) : error C2039: 'assert_not_arg' : is not a member of 'boost::mpl' C:\local\boost\boost/mpl/eval_if.hpp(41) : see reference to class template instantiation 'boost::detail::facade_iterator_category_impl<CategoryOrTraversal,ValueParam,Reference>' being compiled with [ CategoryOrTraversal=boost::forward_traversal_tag , ValueParam=boost::unit_test::basic_cstring<const char> , Reference=boost::unit_test::basic_cstring<const char> ] Here's the link with the complete message: http://www.boost.org/development/tests/release/developer/output/teeks99-10-… It doesn't seem to be a problem with Boost.Atomic but rather some incompatibility of BOOST_MPL_ASSERT_NOT and MSVC-12. Does anyone know what the problem is?

3 8

[config] BOOST_NO_CXX11_HDR_MEMORY and gcc-4.6.2
by Vicente J. Botet Escriba 29 Oct '13

29 Oct '13

Hi, I'm checking for BOOST_NO_CXX11_HDR_MEMORY to include <memory> file with gcc-4.6.2 C++0x and while the file is there (it was a C++98 file),it is not defining in particular pointer_traits and allocator_traits Could the following patch be applied? Best, Vicente svn diff stdlib/libstdcpp3.hpp Index: stdlib/libstdcpp3.hpp =================================================================== --- stdlib/libstdcpp3.hpp (revision 86431) +++ stdlib/libstdcpp3.hpp (working copy) @@ -154,9 +154,11 @@ // Note that although <chrono> existed prior to 4.7, "stead_clock" is spelled "monotonic_clock" // so 4.7.0 is the first truely conforming one. # define BOOST_NO_CXX11_HDR_CHRONO +// C++11 header not yet (fully!) implemented, e.g. pointer_traits and allocator_traits. +# define BOOST_NO_CXX11_HDR_MEMORY # define BOOST_NO_CXX11_ALLOCATOR #endif -// C++0x headers not yet (fully!) implemented +// C++11 headers not yet (fully!) implemented // # define BOOST_NO_CXX11_HDR_THREAD # define BOOST_NO_CXX11_HDR_TYPE_TRAITS

6 14

The release branch is now closed
by Marshall Clow 28 Oct '13

28 Oct '13

Please do not commit anything to the release branch w/o explicit permission from the release managers. -- Marshall

5 4

[1.55] Request permission to merge 86426 to branches/release
by Beman Dawes 28 Oct '13

28 Oct '13

86426 needs to be merged to branches/release. It is a showstopper since without it all msvc tests are broken. It is a one-liner from Steven that simply deletes line 15, " : usage-requirements <implicit-dependency>/boost//headers" from libs/Jamfile.v2. This was was part of a three revision set of patches (86393, 86398, and 86426) that was being held waiting for trunk tests to cycle. The first two got merged yesterday, but the last one was missed in the last minute rush. --Beman

3 3

[config] gcc 4.6 unified initialization syntax buggy
by klaus triendl 28 Oct '13

28 Oct '13

hi, gcc 4.6 (with -std=c++0x) has a bug in its support for unified initialization. specifically a derived class cannot initialize its base with members, if the base has no user-defined constructor: <code> struct base { int i; }; struct derived: base { explicit derived(int i): base{i} {} }; </code> therefore the configuration macro BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX should be fixed... Has this been already addressed? -- klaus triendl

1 0