- Boost - lists.boost.org

[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

[config] clang/int128 support
by Tim Blechmann 28 Oct '13

28 Oct '13

hi all, is it ok to commit this patch? this works around some issues when compiling boost.atomic with clang-3.4: ../../../boost/atomic/detail/gcc-atomic.hpp:961:64: error: no matching constructor for initialization of 'storage_type' (aka 'boost::atomics::detail::storage128_type') explicit base_atomic(value_type const& v) BOOST_NOEXCEPT : v_(0) thnx, tim --- a/boost/config/compiler/clang.hpp +++ b/boost/config/compiler/clang.hpp @@ -39,6 +39,11 @@ // Clang supports "long long" in all compilation modes. #define BOOST_HAS_LONG_LONG +#if defined(__SIZEOF_INT128__) +# define BOOST_HAS_INT128 +#endif + +

2 1

[numeric] Lack headers for ARM CPU
by christine bouzant 28 Oct '13

28 Oct '13

Hello all, I would need to include the header boost/numeric/interval/hw_rounding.hpp but i see that the ARM CPU is not taken in account. Is someone would have a non official header version for the ARM cpu case ? Thank you! Cheers, Christine

1 0

boost::polygon type genericity
by T. Raykoff 28 Oct '13

28 Oct '13

boost::polygon has a nice facility for generic numeric types for coordinate values via coordinate_traits, etc. But there are a number of places in the library code where a hard-coded type, usually a double, is used instead of referring to the appropriate type in this trait struct. Should this be considered a bug in b::p? Background: I'd like to use a custom class as a type which manages the scaling of real-world decimal coordinates to the integral values that b::p likes to use. I understand the whole thing about snap-rounding to an integral grid and all that, so need to scale up the real-world decimal values to an appropriate grid size. But it makes sense to carry this paradigm through to all of the typedef's in coordinate_traits and high_precision_type, but this is where things break with the hard-coded double's. T -- View this message in context: http://boost.2283326.n4.nabble.com/boost-polygon-type-genericity-tp4651484.… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 10