- Boost - lists.preview.boost.org

[exception] c++11 updates
by Ryan Burn 21 Mar '15

21 Mar '15

I've been working with boost exception and looking at the develop branch on github it looks like much of it hasn't been updated for c++11. Is anyone already working on this already? If not, I'd like to make the following changes: - add rvalue-reference overloads to the error_info class ( https://github.com/boostorg/exception/blob/develop/include/boost/exception/…) and elsewhere so that you can do things like throw my_error() << my_info(std::move(a)) - replace occurrences of "throw()" with a macro (something like BOOST_NO_THROW_SPECIFICATION) that expands to "throw()" if compiling with c++98 and "noexcept" if compiling >= c++11 would these changes be ok? Thanks, Ryan

2 2

Re: [boost] enhanced vector and deque competency test
by Islam Taha 20 Mar '15

20 Mar '15

Thank you again I think it’s solved right now, you can check it Thanks in advance Islam Taha

3 3

[1.58] Request to add fix for ticket #6766 to 1.58 release
by Aparna Kumta 20 Mar '15

20 Mar '15

Boost ticket #6766 ( https://svn.boost.org/trac/boost/ticket/6766 ) affects several of our tests running with Oracle Solaris Studio compiler. It prevents building of libboost_unit_test_framework.a which in turn causes tests from many of the libraries (accumulators, algorithm, assign, lexical_cast, msm, odeint, polygon, range and sync) to fail due to a dependency on libboost_unit_test_framework.a. A PR for this has been submitted.https://github.com/boostorg/test/pull/36 This fix alone causes the pass rate for Boost 1.58 with the Oracle Solaris Studio compiler to increase by about 15%. This fix is not in the 'develop' branch yet. We would very much appreciate if this could be considered for putback into the Boost 1.58 release. Thanks, Aparna

1 0

Re: [boost] enhanced vector and deque competency test
by Islam Taha 20 Mar '15

20 Mar '15

Thank you very much I have now removed all warnings and it removed the segmentation fault as well. It would be appreciated to give me another feedback on the updated code. thanks in advance

2 1

[1.58] Developchanges not yet merged to master?
by Beman Dawes 20 Mar '15

20 Mar '15

FWIW, I got a private email worrying about unmerged fixes: > This is the list of PR's that have been merged into the develop branch but > have not made it into the 1.58 release candidate: > > https://github.com/boostorg/serialization/pull/9 > https://github.com/boostorg/odeint/pull/7 > https://github.com/boostorg/odeint/pull/6 > https://github.com/boostorg/pool/pull/7 > https://github.com/uBLAS/ublas/pull/26 > https://github.com/boostorg/odeint/pull/9 > https://github.com/boostorg/odeint/pull/8 > https://github.com/boostorg/lexical_cast/pull/10 > https://github.com/boostorg/type_traits/pull/11 > https://github.com/boostorg/type_index/pull/6 I asked the sender to post this sort of message directly to the list, but with 1.58.0 so close it seemed worthwhile to send the list along. --Beman

3 2

Re: [boost] [gsoc15] Removing my proposal due to plagiarism concerns
by Islam Taha 20 Mar '15

20 Mar '15

I’m sorry to fork your README file on your rep. i was just concerned to know how to make bold and somethings you do in your file, there is nothing to do with plagiarism with this, don’t worry about your proposal. Apologizes Islam Taha

1 0

Windows Develop Tests Failing
by Tom Kent 20 Mar '15

20 Mar '15

All my windows test runners for develop (teeks99-08*) have been failing for the last few days (I just noticed). They run for a long while, then end with the following at the end of their results/bjam.log file: common.mkdir D:\local\teeks99-08\d\results\boost\bin.v2\libs\multiprecision\test\number_concept_check_cpp_dec_float_no_et.test\msvc-11.0\debug\address-model-64\architecture-x86\debug-symbols-off\link-static\runtime-link-static if not exist "D:\local\teeks99-08\d\results\boost\bin.v2\libs\multiprecision\test\number_concept_check_cpp_dec_float_no_et.test\msvc-11.0\debug\address-model-64\architecture-x86\debug-symbols-off\link-static\runtime-link-static\\" mkdir "D:\local\teeks99-08\d\results\boost\bin.v2\libs\multiprecision\test\number_concept_check_cpp_dec_float_no_et.test\msvc-11.0\debug\address-model-64\architecture-x86\debug-symbols-off\link-static\runtime-link-static" failed to write output file 'D:\local\teeks99-08\d\results\boost\bin.v2\libs\multiprecision\test\number_concept_check_cpp_dec_float_no_et.test\msvc-11.0\debug\address-model-64\architecture-x86\debug-symbols-off\link-static\runtime-link-static\number_concept_check_cpp_dec_float_no_et.obj.rsp'! At first I thought I might be running out of disk space or something, but that all seems fine. Has anyone seen this before? Tom

12 26

Testing develop fails with b2 errors
by Peter Dimov 20 Mar '15

20 Mar '15

LIke this: C:\Projects\boost-git\boost\libs\core\test>b2 toolset=clang,clang-cxx11,gcc,gcc-cxx11,msvc-8.0,msvc-10.0,msvc-11.0,msvc-12.0 [...] C:/Projects/boost-git/boost/tools/build/src/build\project.jam:262: in find-jamfile from module project error: Unable to load Jamfile. error: Could not find a Jamfile in directory '/C:/Projects/boost-git/boost/libs/context/config'. error: Attempted to find it with pattern '[Bb]uild.jam [Jj]amfile.v2 [Jj]amfile[Jj]amfile.jam'. error: Please consult the documentation at 'http://www.boost.org'. and then this: C:/Projects/boost-git/boost/tools/build/src/build\project.jam:280: in load-jamfile from module project C:/Projects/boost-git/boost/tools/build/src/build\project.jam:64: in project.load from module project C:/Projects/boost-git/boost/libs/log/build\log-architecture.jam:23: in load from module log-architecture C:/Projects/boost-git/boost/tools/build/src/kernel\modules.jam:289: in modules.import from module modules C:/Projects/boost-git/boost/tools/build/src/build\project.jam:1043: in import from module Jamfile<C:\Projects\boost-git\boost\libs\log\build> ..\..\..\libs\log\build\Jamfile.v2:15: in modules.load from module Jamfile<C:\Projects\boost-git\boost\libs\log\build> C:/Projects/boost-git/boost/tools/build/src/build\project.jam:325: in load-jamfile from module project C:/Projects/boost-git/boost/tools/build/src/build\project.jam:64: in load from module project C:/Projects/boost-git/boost/tools/build/src/build\project.jam:89: in load-used-projects from module project C:/Projects/boost-git/boost/tools/build/src/build\project.jam:75: in load from module project C:/Projects/boost-git/boost/tools/build/src/build\project.jam:113: in load-parent from module project C:/Projects/boost-git/boost/tools/build/src/build\project.jam:464: in initialize from module project C:/Projects/boost-git/boost/tools/build/src/build\project.jam:306: in load-jamfile from module project C:/Projects/boost-git/boost/tools/build/src/build\project.jam:64: in load from module project C:/Projects/boost-git/boost/tools/build/src/build\project.jam:113: in load-parent from module project C:/Projects/boost-git/boost/tools/build/src/build\project.jam:464: in initialize from module project C:/Projects/boost-git/boost/tools/build/src/build\project.jam:306: in load-jamfile from module project C:/Projects/boost-git/boost/tools/build/src/build\project.jam:64: in load from module project C:/Projects/boost-git/boost/tools/build/src/build\project.jam:145: in project.find from module project C:/Projects/boost-git/boost/tools/build/src\build-system.jam:535: in load from module build-system C:\Projects\boost-git\boost\tools\build\src/kernel\modules.jam:289: in import from module modules C:\Projects\boost-git\boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build from module C:\Projects\boost-git\boost\boost-build.jam:17: in module scope from module

5 7

To split, or not to split, or something else? RE: type_traits rewrite, modularization, dependencies, etc.
by Rene Rivera 20 Mar '15

20 Mar '15

I keep reading emails about the effort to reduce dependencies, and to split libraries into core/simple + whole/big.. And I keep thinking it's making things more complex than they need to be. I can see the need to compartmentalize the parts of a library that have minimal to little dependencies. So here's a suggestions for structure of managing this. I see options: 1. In each library allow for a "core" set of headers that are still in a core subdir. But that we can tell is a subset of the library that has the minimal dependencies. For example we would have: * libs/<lib>/include/boost/<lib>/core/.. * libs/<lib>/include/boost/<lib>/<the-rest>.. This of course assumes that it's headers only that would be core. Second option is to have each library have to explicit sublibs/parts. "core" and "full". Structure would be: * libs/<lib>/core/(build, doc, include, meta, test) * libs/<lib>/full/(build, doc, include, meta, test) Note, both core and full would be in the same git repo to make life easier for library authors and users that visit a library git repo on github. As it's only one place for everything for that one library. As a user, release manager, testing manager, and library author this would be easy to understand and manage than the current "some random set of libraries have core or not and in different places". -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

6 11

[1.58.0] Request permission to merge smart_ptr:94824c8 into master
by Peter Dimov 20 Mar '15

20 Mar '15

This https://github.com/boostorg/smart_ptr/commit/94824c807f76dc4f3d41109a75808e… fixes a problem on QNX/Blackberry by adding std:: to ptrdiff_t, in a place where size_t is already similarly qualified, so it should be very low risk. Tested locally on g++ 4.8.3, clang-3.4.2, msvc-8.0, msvc-10.0, msvc-11.0, msvc-12.0.

2 1