- Boost - lists.preview.boost.org

Travis CI again.
by John Maddock 23 Jun '19

23 Jun '19

Sorry, but I need help, and simply can not see what's going wrong with: https://github.com/boostorg/config/pull/286. Travis doesn't even seem to be building the same code as has been pushed? And until I can get CI functioning again here, and in other libraries, nothing gets merged to master :( Sorry if I'm being dense, and thanks in advance, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 4

[release] 1.71.0 deadline for new libraries approaching
by Michael Caisse 22 Jun '19

22 Jun '19

One week from today master will closed for new libraries and breaking changes. Thanks, -- The Boost Release Team Boost Calendar with the release schedule: <http://www.boost.org/development/index.html>

3 4

[process][type_erasure] Including both process and type_erasure creates duplicate definitions in mp11 and fusion
by Jared McIntyre 21 Jun '19

21 Jun '19

I've found that type_erasure::any and process::child conflict with each other in how they use mp11 and fusion. The issue may be specific to compiling the process library on Windows as it occurs in calls through detail headers in the library that are specific to Windows, and I haven't tested on other platforms.. #include <boost/type_erasure/any.hpp> #include <boost/process/child.hpp> Order doesn't matter. 1>c:\<removed>\boost\boost\fusion\adapted\std_tuple\tag_of.hpp(38): error C2953: 'boost::mpl::sequence_tag<std::tuple<_Types...>>': class template has already been defined 1>c:\<removed>\boost\boost\mp11\mpl.hpp(155): note: see declaration of 'boost::mpl::sequence_tag<std::tuple<_Types...>>' Boost 1.67, 1.70 VS 2017 (5.9.12)

1 0

[boost-developers] [MSVC142] When is boost going to add MSVC 14.2 as a test compiler
by Alex J 21 Jun '19

21 Jun '19

Hi, I can see that boost has updated their code to support MSVC14.2 builds. However according to latest 1.70 docs, they are not testing on 14.2 compiler. When can we expect boost to include 14.2 as one of their primary test compilers ? Thanks Alex

2 1

Re: [boost] [release] 1.71.0 deadline for new libraries approaching
by Kenneth Porter 20 Jun '19

20 Jun '19

Can we get this fix into the crc library? It fixes a warning in MSVC compilers. <https://github.com/boostorg/crc/pull/2>

1 0

CMake config scripts broken in 1.70
by Alexander Grund 19 Jun '19

19 Jun '19

Hi all, I discovered a severe logic flaw in the generated CMake Config files for the new Boost 1.70 which make them almost unusable. As an example the static variant contains: if(NOT"${Boost_USE_STATIC_LIBS}"STREQUAL""ANDNOTBoost_USE_STATIC_LIBS) _BOOST_SKIPPED("libboost_filesystem.a""static, Boost_USE_STATIC_LIBS=${Boost_USE_STATIC_LIBS}") return() endif() if(BUILD_SHARED_LIBS) _BOOST_SKIPPED("libboost_filesystem.a""static, BUILD_SHARED_LIBS=${BUILD_SHARED_LIBS}, set Boost_USE_STATIC_LIBS=ON to override") return() endif() The shared variant contains: if(NOT"${Boost_USE_STATIC_LIBS}"STREQUAL""ANDBoost_USE_STATIC_LIBS) _BOOST_SKIPPED("libboost_filesystem.so.1.70.0""shared, Boost_USE_STATIC_LIBS=${Boost_USE_STATIC_LIBS}") return() endif() if(NOTBUILD_SHARED_LIBS) _BOOST_SKIPPED("libboost_filesystem.so.1.70.0""shared, BUILD_SHARED_LIBS not ON, set Boost_USE_STATIC_LIBS=OFF to override") return() endif() Although the message text says otherwise the 2nd return in both cases depends solely on BUILD_SHARED_LIBS. I'm pretty sure the intention was too check for BUILD_SHARED_LIBS *only* if Boost_USE_STATIC_LIBS is not set (see thread https://lists.boost.org/Archives/boost/2019/02/245030.php) As can be seen this is not the case. I haven't found the repo which contains the code that generates this so I can't report it there or fix it myself. As the issue here makes using Boost 1.70 (almost) impossible (in Scenarios like BUILD_SHARED_LIBS=ON (a CMake variable influencing the project build) and Boost_USE_STATIC_LIBS=ON) I'd recommend fixing this and pushing out a bugfix release. Regards, Alexander Grund

2 4

Re: [boost] [Boost.Config] Detect compiler support for std::current_exception
by dariomt＠gmail.com 19 Jun '19

19 Jun '19

> > >>> 2) How can I test proper support for std::current_exception() and > >>> std::rethrow_exception() if exceptions are disabled for the test? > >> > >> You should probably condition your test on BOOST_NO_EXCEPTIONS and make > >> the test no-op when exceptions are disabled. > > > > But that defeats the whole purpose of having tests. > > Not really. You would still test the facilities when exceptions are > enabled. OTOH, I don't see why would anyone care about these components > when exceptions are disabled. > > If the Jamfile disables exceptions for the library tests, then I think I need to care. Otherwise this config macro would be untested. > > I think I should at least use the type std::exception_ptr, and make sure > > the functions std::current_exception() and std::rethrow_exception() exist > > (even if I cannot test that they actually work as expected at runtime). > > > > I think the following should work, and at least the test tests something > > when exceptions are off: > > > > using std::exception_ptr; > > auto current = &std::current_exception; > > auto rethrow = &std::rethrow_exception; > > > > What do you think? > > If it works, that would be fine by me. I don't disable exceptions and I > don't know whether the standard library components related to exceptions > stay available when exceptions are disabled. I wouldn't be surprised if > they don't (now or in a future version of the standard library > implementation). In any case, as I said, I don't see anyone using these > components when exceptions are disabled, so not much point in testing. > > In the end I settled for using std::exception_ptr; using std::current_exception; using std::rethrow_exception; because some old version of clang had issues with auto, sigh... The problem now is that something else is broken in the CI tests, but I'm quite confident that the tests should pass in all of msvc, gcc, clang I'd like to ask for the PR #285 to be merged into develop please ( https://github.com/boostorg/config/pull/285) Thanks!

1 0

Ticket #9804 - polygon intersection
by Michael Knafo MTH 19 Jun '19

19 Jun '19

Hello ! I have encountered the same problem described in bug #9804: "The result of an intersection is sometimes equal to one of the input polygons, when the result should be empty". https://svn.boost.org/trac10/ticket/9804 Does anyone knows if this bug was fixed and in which boost version ? Is there any version release notes related to this bug ? Alternatively, does anybody know what cause this problem ? Thanks Michael *********************************************************************************************** Please consider the environment before printing this email ! The information contained in this communication is proprietary to Israel Aerospace Industries Ltd. and/or third parties, may contain confidential or privileged information, and is intended only for the use of the intended addressee thereof. If you are not the intended addressee, please be aware that any use, disclosure, distribution and/or copying of this communication is strictly prohibited. If you receive this communication in error, please notify the sender immediately and delete it from your computer. Thank you. Visit us at: www.iai.co.il

2 2

Proposed for inclusion in boost: a C++11 span
by Hans Dembinski 17 Jun '19

17 Jun '19

Dear all, I started to work on a C++11 implementation of std::span. The interface will be an exact mirror of std::span, https://en.cppreference.com/w/cpp/container/span. Having a drop-in replacement of std::span for systems with older compilers in Boost seems like a very good idea. Is anyone else already working on this? I am happy to join forces. Coding down the span took me an hour, but several more hours will go into unit testing and documenting. Best regards, Hans

3 4

Re: [boost] [Boost.Config] Detect compiler support for std::current_exception
by dariomt＠gmail.com 17 Jun '19

17 Jun '19

> > > > > However, in my test I throw and catch exceptions: > > But the CI jobs have gcc and clang configured to compile without > exception > > support! > I have two questions: > > > > 1) Where are exceptions disabled in the CI jobs? I can't find it in > > the .travis.yml, > > but I can see e.g. clang being invoked with -fno-exceptions > > It's in the test/Jamfile.v2 file, look for <exception-handling>off. > Thanks! > > > 2) How can I test proper support for std::current_exception() and > > std::rethrow_exception() if exceptions are disabled for the test? > > You should probably condition your test on BOOST_NO_EXCEPTIONS and make > the test no-op when exceptions are disabled. > But that defeats the whole purpose of having tests. I think I should at least use the type std::exception_ptr, and make sure the functions std::current_exception() and std::rethrow_exception() exist (even if I cannot test that they actually work as expected at runtime). I think the following should work, and at least the test tests something when exceptions are off: using std::exception_ptr; auto current = &std::current_exception; auto rethrow = &std::rethrow_exception; What do you think?

2 1