- Boost - lists.preview.boost.org

FWD: [cfe-users] Boost.GIL test failing with clang 5.x while pass with 15 gcc/clang versions
by Mateusz Loskot 21 May '18

21 May '18

Hi, I posted this to clang mailing list a http://lists.llvm.org/pipermail/cfe-users/2018-May/001335.html but since it is related to Boost.GIL bugs I'm investigating, I'd like to reach for feedback here too. I'll appreciate any comments regarding the issue explained below. ML ---------- Forwarded message ---------- From: Mateusz Loskot <mateusz(a)loskot.net> Date: 19 May 2018 at 21:38 Subject: Boost.GIL test failing with clang 5.x while pass with 15 gcc/clang versions To: cfe-users(a)lists.llvm.org Hi, While testing Boost.GIL library [1] with gcc and clang, I noticed a peculiar issue. One particular test is failing with lang 5.x while passing with total of 15-17 other versions of clang and GCC (total workflow of CircleCI with at [2]). Below is extracted minimal program equivalent to Boost.GIL channel_invert algorithm. It includes two variants: plain expression and the same expression wrapped with a function template: #include <limits> #include <iostream> #include <typeinfo> template <typename C> inline C channel_invert1(C x) { return std::numeric_limits<C>::max() - x + std::numeric_limits<C>::min(); } template <typename C> inline C channel_invert2(C x) { return (x - std::numeric_limits<C>::max()) * (-1) + std::numeric_limits<C>::min(); } int main() { int x = std::numeric_limits<int>::min(); std::cout << x << std::endl; // plain expressions int x_invert1 = std::numeric_limits<int>::max() - x + std::numeric_limits<int>::min(); int x_invert2 = (x - std::numeric_limits<int>::max()) * (-1) + std::numeric_limits<int>::min(); std::cout << x_invert1 << std::endl; std::cout << x_invert2 << std::endl; // the same expressions wrapped in function template std::cout << channel_invert1<int>(x) << std::endl; std::cout << channel_invert2<int>(x) << std::endl; } If compiled as optimised variant (-O2 or -O3) with clang 5.x outputs the following: -2147483648 2147483647 2147483647 -1 -1 The last two negative one is not expected. If compiled with clang 3.9, 4.0 or gcc from 5.1 to 7.3 it outputs -2147483648 2147483647 2147483647 2147483647 2147483647 Could anyone help me to understand what is going on in the clang 5 case? Or, what UB is this hitting? [1] https://github.com/boostorg/gil/issues/89 [2] https://circleci.com/workflow-run/3a14dd64-6c38-46b2-a6da-678c0075ca27 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

Enabling issues on boostorg/mpi
by Alain Miniussi 21 May '18

21 May '18

Hi, Could somebody with the sufficient permissions enable issues on the github mpi repository ? Thanks Alain Miniussi

2 2

Proposal for a thread synchronisation primitive: future_queue
by Martin Hierholzer 21 May '18

21 May '18

Dear boost developers, I want to propose a thread synchronisation primitive, which works like a mixture of (lockfree) queues and futures. Therefore I gave it the name "future_queue". It is basically a lockfree queue which can be waited on for new values (without busy waiting), but it has some nice extra features like when_any() and continuations. The github project can be found here: https://github.com/mhier/future_queue It already contains a README file with a short description, an example and results of a first performance measurement. Further documentation so far exists only inside the code: https://github.com/mhier/future_queue/blob/master/include/future_queue.hpp My first question is, whether this is really something new (I might have overlooked something in the many boost libraries) and if it makes sense to integrate it into the boost libraries. Another question would be whether this should really be its own library, since it is basically a single class (with a few helper classes) and a single non-member function. Maybe it would be better to make it part of an existing library? I am happy to receive some first feedback! Cheers, Martin -- Martin Hierholzer DESY Notkestrasse 85 22607 Hamburg Office 55a / 123 Tel: +49 40 8998 1897 Mob: +49 176 992 46 476 Skype: mhier48 This e-mail may contain confidential and/or privileged information and is intended only for the use of the individual or entity named above. If you received it in error, please advise the sender immediately by reply e-mail and delete the original. Any further use - especially any form of publication - of this e-mail without explicit authorisation is strictly prohibited.

4 11

[Hana] "basic_tuple.hpp" bug when building with VS2017
by Daniel Chen 20 May '18

20 May '18

Hello, Just installed Boost and Visual Studio 2017 a few days ago. Here is a bug when building with Hana's "basic_tuple.hpp" header with Visual Studio 2017: In basic_tuple.hpp: template <> struct drop_front_impl<basic_tuple_tag> { template <std::size_t N, typename Xs, std::size_t ...i> static constexpr auto drop_front_helper(Xs&& xs, std::index_sequence<i...>) { return hana::make_basic_tuple( detail::ebo_get<detail::bti<i+N>>(static_cast<Xs&&>(xs))... ); } template <typename Xs, typename N> static constexpr auto apply(Xs&& xs, N const&) { constexpr std::size_t len = detail::decay<Xs>::type::size_; return drop_front_helper<N::value>(static_cast<Xs&&>(xs), std::make_index_sequence< N::value < len ? len - N::value : 0 >{}); //<Bug here - line 197 of basic_tuple.hpp } }; Upon building with "basic_tuple.hpp", the line highlighted in green reports an error: "syntax error: unexpected token ')', expected 'id-expression'". Focus on the line above that one: N::value < len ? len - N::value : 0 If you add parentheses, the error goes away: (N::value < len) ? len - N::value : 0 A similar bug occurs - and is fixed likewise - in the "string.hpp" header file at line 275, that is: template <> struct drop_front_impl<string_tag> { ... template <char ...xs, typename N> static constexpr auto apply(string<xs...> const& s, N const&) { return helper<N::value>(s, std::make_index_sequence< N::value < sizeof...(xs) ? sizeof...(xs) - N::value : 0 >{}); //<bug here - line 275 of string.hpp } I'm not sure if this is a Microsoft compiler issue (I will post to them as well), but I feel like someone should add those parentheses (and then some) to the line since it is safer - the "<" can be easily confused for a template bracket instead of a less-than sign by a parser. Daniel Chen Infinera

2 1

Boost.Test, cygwin, and ISO/POSIX
by James E. King, III 19 May '18

19 May '18

Hello, I have been adding some CI infrastructure to the CMT repositories and found I am able to reproduce a failure building boost libraries that use Boost.Test for their unit tests. If you build with "cxxstd=03" you can get to some undefined functions. See: https://github.com/boostorg/test/issues/144 It looks like one needs to define _POSIX_C_SOURCE=200112L or cxxstd-dialect=gnu in order for these functions to become visible. I was thinking of addressing this two ways: 1. I want to change boost build (bjam) to define _POSIX_C_SOURCE when building on cygwin to this value if it is not otherwise defined. I can't find the right place to add this. 2. I don't think it's reasonable for Boost.Test to modify _POSIX_C_SOURCE since it could be included after sys/functional header, so I would like to either change Boost.Test so it does not depend on these three functions, or check to see if the right preprocessor definitions are set on cygwin and put up a better error message, or simply change the documentation and update all the CI build scripts in all the affected repositories to set _POSIX_C_SOURCE as part of the CI build. Any thoughts or other ideas on this? Thanks, Jim

1 0

disjoint_sets repo status
by James E. King, III 17 May '18

17 May '18

What is the current status of https://github.com/boostorg/disjoint_sets ? The headers appear to be in a "pending" state. There's almost nothing in this repo. Perhaps it was put here to solve a circular dependency issue? It looks like it is used by graph and graph_parallel. Could we move this into Boost.Algorithm? Thanks, Jim

1 0

[release][chrono] libs/chrono/stopwatches/include not in boost/chrono/stopwatches
by Andrey Semashev 17 May '18

17 May '18

Hi, In the 1.67 released archive, there is libs/chrono/stopwatches/include directory that contains headers that look like they should be placed in boost/chrono/stopwatches. With the checkout from git, `b2 headers` create links boost/chrono/stopwatches and boost/chrono/stopwatches.hpp that refer to that directory. Looks like the packaging scripts need to be updated.

2 1

dynamic_bitset needs some attention
by James E. King, III 16 May '18

16 May '18

I have been adding a common CI infrastructure to the CMT repositories. Occasionally I have to disable one or two build jobs to get a clean build and I file an issue. When I got to dynamic_bitset however, there's clearly something going on in there and it isn't good. I think it has to do with streaming. It's probably just one issue causing most of the failures. You can see the results from my latest dry-run PR here: https://github.com/jeking3/dynamic_bitset/pull/1 Right now both the main travis and all of the appveyor builds are failing, and they all look like they get stuck on test 4 in iostream processing. Something just isn't right in there - it could be the test itself or it could be something else. I may submit a PR into the repo for the CI additions anyway even if they are failing, since it points out this component has rotted and needs attention. Also if my PRs in pool and function can be merged, we'll have better CI on those. Aiming to get all the CMT repos covered with appveyor, travis, codecov, and eventually covscan. - Jim

1 0

Clarifying Boost evolution plans mentioned on Twitter
by Bryce Adelstein Lelbach aka wash 16 May '18

16 May '18

Hi all, Some pictures from the C++Now "Boost Library In A Week" end-of-week summary were posted to Twitter today by an attendee, along with some mistaken statements suggesting that "Boost plans to move to C++11". I want to clarify what is actually going on: 0.) During the week, the Library In A Week group discussed some ideas for how Boost might migrate to newer standards. I'm somewhat to blame as I initiated these discussions. 1.) Those ideas were collected into a draft document by Jeff Garland. 2.) During the closing panel, Jeff presented the draft document and stated the next step would be to share it with the mailing list. 3.) Due to an innocent misunderstanding, an attendee posted a picture of part of the document with the unclear message "Boost plans to move to C++11". 4.) I wrote this email. I have asked the attendee to delete the tweet (and repost with a clearer message if they wish). I don't want to share the document from LIAW. Jeff put a lot of work into it and I don't want to steal his thunder (I realize this email inevitably does that). I'm sure he will follow up with a post explaining what ideas we came up with soon. I'm very sorry for the confusion, and I'm sure the attendee is as well. This was just an innocent mixup. ------------------------------------------------------ Bryce Adelstein Lelbach aka wash ISO C++ Committee Member CppCon and C++Now Program Chair Thrust Maintainer, HPX Developer CUDA Convert and Reformed AVX Junkie Sleep is for the weak ------------------------------------------------------

4 3

[interprocess]Request to support wchar_t* file name on Windows
by 孙朝阳 15 May '18

15 May '18

Hi, I'm using boost.interprocess.file_mapping on Windows, and I need to use it to open files with localized file path, so I want file_mapping can support wchar_t file name on Windows. Does any reason prevent file_mapping to support wchar_t file name? If no, would someone like to add wchar_t supporting for file_mapping? I also created a pull request for this: https://github.com/boostorg/interprocess/pull/28 Thanks, Jackson Sun

1 0

boost libs compiled for gcc toolset with boost 1.67 and CMake 3.11 won't find libs
by Demetri Kopsas 12 May '18

12 May '18

Hi, I discovered that the latest version of boost does not work with CMake when using the GCC toolset. I submitted this bug: https://gitlab.kitware.com/cmake/cmake/issues/17974#note_408614 Using MSVC as the toolset is fine on windows, but using mingw (gcc compiler) cannot find the libs unless I take out ‘x32’ or ‘x64’ from the name after compilation.

2 1

[build] recent issues w. VS 2017
by Raffi Enficiaud 12 May '18

12 May '18

Dear all, I am experiencing an issue with VS 2017 (15.6.6) while compiling boost.test on my agent. Traces below. I do not recall having applied any change to this agent apart from installing C++/CLI support for CMake people. Is this problem known? Thanks, Raffi build 01-May-2018 11:43:49 D:\bamboo_build_dir\SW-BCB161-VC2017WIN\library\libs\test\test>..\..\..\b2 --abbreviate-paths toolset=msvc-14.1 cxxflags="/std:c++latest" build 01-May-2018 11:43:50 Performing configuration checks build 01-May-2018 11:43:50 build 01-May-2018 11:43:50 - default address-model : 32-bit (cached) build 01-May-2018 11:43:50 - default architecture : x86 (cached) build 01-May-2018 11:43:50 - symlinks supported : no (cached) build 01-May-2018 11:43:50 - junctions supported : yes (cached) build 01-May-2018 11:43:50 - hardlinks supported : yes (cached) build 01-May-2018 11:43:51 - BOOST_COMP_GNUC >= 4.3.0 : no build 01-May-2018 11:43:54 - Boost.Config Feature Check: cxx11_auto_declarations : no build 01-May-2018 11:43:54 - Boost.Config Feature Check: cxx11_function_template_default_args : no build 01-May-2018 11:43:54 - Boost.Config Feature Check: cxx11_lambdas : no build 01-May-2018 11:43:55 - Boost.Config Feature Check: cxx11_hdr_initializer_list : no build 01-May-2018 11:43:55 - Boost.Config Feature Check: cxx11_template_aliases : no build 01-May-2018 11:43:55 - Boost.Config Feature Check: cxx11_decltype : no build 01-May-2018 11:43:55 - Boost.Config Feature Check: cxx11_hdr_random : no build 01-May-2018 11:43:55 - Boost.Config Feature Check: cxx11_hdr_tuple : no build 01-May-2018 11:43:55 - Boost.Config Feature Check: cxx11_variadic_macros : no build 01-May-2018 11:43:55 - Boost.Config Feature Check: cxx11_trailing_result_types : no build 01-May-2018 11:43:56 - Boost.Config Feature Check: cxx11_nullptr : no build 01-May-2018 11:43:56 - Boost.Config Feature Check: cxx11_unified_initialization_syntax : no build 01-May-2018 11:43:56 - Boost.Config Feature Check: cxx11_variadic_templates : no build 01-May-2018 11:43:57 - Boost.Config Feature Check: cxx11_decltype : no build 01-May-2018 11:43:57 - Boost.Config Feature Check: cxx11_hdr_random : no build 01-May-2018 11:43:57 - Boost.Config Feature Check: cxx11_hdr_tuple : no build 01-May-2018 11:43:57 - Boost.Config Feature Check: cxx11_hdr_initializer_list : no build 01-May-2018 11:43:57 - Boost.Config Feature Check: cxx11_variadic_macros : no build 01-May-2018 11:43:57 - Boost.Config Feature Check: cxx11_trailing_result_types : no build 01-May-2018 11:43:57 - Boost.Config Feature Check: cxx11_template_aliases : no build 01-May-2018 11:43:57 ...patience... build 01-May-2018 11:43:57 ...found 3946 targets... build 01-May-2018 11:43:57 ...updating 553 targets... build 01-May-2018 11:43:58 compile-c-c++ ..\..\..\bin.v2\libs\test\test\string_cast-test.test\msvc-14.1\dbg\thrd-mlt\utils-ts\string_cast-test.obj build 01-May-2018 11:43:58 string_cast-test.cpp build 01-May-2018 11:43:58 D:\bamboo_build_dir\SW-BCB161-VC2017WIN\library\boost/config/detail/select_stdlib_config.hpp(18): fatal error C1083: Cannot open include file: 'cstddef': No such file or directory build 01-May-2018 11:43:58 build 01-May-2018 11:43:58 call "..\..\..\bin.v2\standalone\msvc\msvc-14.1\msvc-setup.bat" >nul build 01-May-2018 11:43:58 cl /Zm800 -nologo @"..\..\..\bin.v2\libs\test\test\string_cast-test.test\msvc-14.1\dbg\thrd-mlt\utils-ts\string_cast-test.obj.rsp" build 01-May-2018 11:43:58 build 01-May-2018 11:43:58 ...failed compile-c-c++ ..\..\..\bin.v2\libs\test\test\string_cast-test.test\msvc-14.1\dbg\thrd-mlt\utils-ts\string_cast-test.obj... build 01-May-2018 11:43:58 compile-c-c++ ..\..\..\bin.v2\libs\test\build\msvc-14.1\dbg\lnk-sttc\thrd-mlt\compiler_log_formatter.obj

3 5

new b2 property or new boost library?
by Oliver Kowalke 11 May '18

11 May '18

Hi, boost.fiber provides some rudimentary NUMA support. NUMA specific OS APIs require the native thread handle (native_handle_type std::thread::native_handle()). But unfortunately the returned type does not match in all cases the OS handle type. For instance MinGW-W64 using the POSIX thread impl returns long long instead of void*. A solution would be to add an additional b2 property like `numa=on` that compiles the NUMA related part of boost.fiber if set (the user is responsible to compile boost with the appropriate properties). Or the NUMA related code is move from boost.fiber into a complete new boost library. What would be you advice? Oliver

1 0

[type_traits] revisiting is_virtual_base_of
by John Maddock 10 May '18

10 May '18

There is a problem with is_virtual_base_of in that it doesn't work especially well - most of the time it works OK, but can be made to fail catastrophically in a few situations, see for example: https://svn.boost.org/trac10/ticket/11323 Now... it turns out that with C++14 and later we now have is_detected which can test the validity of almost any expression... and I'm wondering if there's a cunning way to press this into action to create a more accurate is_virtual_base_of, but I'm having trouble coming up with anything. Any bright ideas? Note that an explicit static_cast can't be tested for, though we can use is_constructible if required. Thanks in advance, John. --- This email has been checked for viruses by AVG. http://www.avg.com

2 3

build failure in develop: chrono, type_traits?
by James E. King, III 08 May '18

08 May '18

The only change in my pull request was to remove a deprecated, unrelated header in uuid. This happened in the builds last night on develop: In file included from ./boost/config.hpp:61:0, from ./boost/chrono/config.hpp:15, from ./boost/chrono/detail/inlined/process_cpu_clocks.hpp:15, from libs\chrono\src\process_cpu_clocks.cpp:17: ./boost/type_traits/detail/common_arithmetic_type.hpp:209:27: error: duplicate 'const' BOOST_STATIC_CONSTANT(const int, selector = sizeof(select(cond() ? T() : U()))); ^ "x86_64-w64-mingw32-g++.exe" -std=c++03 -m64 -O0 -fno-inline -Wall -pedantic -g -Wextra -Wno-long-long -DBOOST_ALL_NO_LIB=1 -DBOOST_All_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -I"." -c -o "bin.v2\libs\chrono\build\gcc-mingw64\debug\cxxstd-03-iso\link-static\process_cpu_clocks.o" "libs\chrono\src\process_cpu_clocks.cpp" ...failed gcc.compile.c++ bin.v2\libs\chrono\build\gcc-mingw64\debug\cxxstd-03-iso\link-static\process_cpu_clocks.o... Failed on cygwin and mingw builds: https://ci.appveyor.com/project/jeking3/uuid-gaamf/build/1.0.116-develop/jo… Also failed in c++03 builds on unix: https://travis-ci.org/boostorg/uuid/jobs/376161574#L2158 gcc.compile.c++ ../../bin.v2/libs/chrono/build/gcc-7/release/cxxstd-03-iso/link-static/thread_clock.o In file included from ../../boost/config.hpp:61:0, from ../../boost/chrono/config.hpp:15, from ../../boost/chrono/detail/inlined/thread_clock.hpp:14, from ../../libs/chrono/src/thread_clock.cpp:18: ../../boost/type_traits/detail/common_arithmetic_type.hpp:209:27: error: duplicate ‘const’ BOOST_STATIC_CONSTANT(const int, selector = sizeof(select(cond() ? T() : U()))); ^ "g++-7" -std=c++03 -m64 -O3 -finline-functions -Wno-inline -Wall -pedantic -Wextra -Wno-long-long -DBOOST_ALL_NO_LIB=1 -DBOOST_All_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"../.." -c -o "../../bin.v2/libs/chrono/build/gcc-7/release/cxxstd-03-iso/link-static/thread_clock.o" "../../libs/chrono/src/thread_clock.cpp" ...failed gcc.compile.c++ ../../bin.v2/libs/chrono/build/gcc-7/release/cxxstd-03-iso/link-static/thread_clock.o... Thanks, Jim

2 1

[filesystem] and C++17 std::filesystem
by Egor Pugin 07 May '18

07 May '18

Hi! gcc8.1 and VS15.7 (2017) are now shipped with std::filesystem. I'd like to raise a discussion about pure c++ interoperability with boost(::filesystem). With boost-1.67 it's not possible to do such things: #if __has_include(<filesystem>) #include <filesystem> namespace fs = std::filesystem; #else #include <boost/filesystem.hpp> namespace fs = boost::filesystem; #endif Because of boost::filesystem::copy_option::overwrite_if_exists != std::filesystem::copy_options::overwrite_existing, std::fs::path() / boost::fs::unique_path(), directory iterators etc. Next, if we take boost::process, for example, we see that it currently operates only on boost::filesystem. If my application uses c++17 fs, I have to write something like this: fs::path f(fs::path in) { bp::search_path(in.u8string()).wstring(); } So, mixing pure c++ and boost becomes more complex. Any ideas how to deal better with such issues on the user side? What are directions of proper fixing this in boost::process (in case I'll try to prepare a PR)? What are boost policies in adopting standard features in general? -- Egor Pugin

2 1

Boost Graph Library(biconnected_components) issue
by Meghana.M Reddy 06 May '18

06 May '18

Hi, I am working on the Boost Graph Library, currently trying to create an interface of the biconnected_components method to a Python code. I used the example code available here <https://www.boost.org/doc/libs/1_67_0/libs/graph/example/biconnected_compon…> for the method and modified it for my purpose. The template of the method is here <https://www.boost.org/doc/libs/1_67_0/libs/graph/doc/biconnected_components…>. The final code seems fine but I get an error while compiling it. And the errors are related to adjacency.hpp which I have not changed so I'm confused as to what the exact problem is. Hoping someone can help me out. My code: class BoostGraph { private: typedef typename boost::adjacency_list< OutEdgeListS, VertexListS, DirectedS, boost::property<boost::vertex_index_t, v_index>, EdgeProperty, boost::no_property, EdgeListS> adjacency_list; typedef typename boost::property_map<adjacency_list, boost::edge_index_t>::type components; public: adjacency_list graph; std::vector<v_index> bc_tree() { components components_bc = get(boost::edge_index, graph); std::size_t num_comps = biconnected_components(graph, components_bc); std::cerr << "Found " << num_comps << " biconnected components.\n"; std::vector<vertex_descriptor> art_points; articulation_points(graph, std::back_inserter(art_points)); std::cerr << "Found " << art_points.size() << " articulation points.\n"; std::vector<v_index> to_return; return to_return; } The error I'm getting: build/cythonized/sage/graphs/base/boost_graph.cpp:3730:26: required from here /home/meghana/Documents/sage_gsoc/sage_may/sage/local/include/boost/graph/detail/adjacency_list.hpp:2696:29: error: forming reference to void typedef value_type& reference; ^ /home/meghana/Documents/sage_gsoc/sage_may/sage/local/include/boost/graph/detail/adjacency_list.hpp:2697:35: error: forming reference to void typedef const value_type& const_reference; ^ /home/meghana/Documents/sage_gsoc/sage_may/sage/local/include/boost/graph/detail/adjacency_list.hpp:2701:61: error: forming reference to void typename Graph::vertex_descriptor,Property,Tag> type; ^ /home/meghana/Documents/sage_gsoc/sage_may/sage/local/include/boost/graph/detail/adjacency_list.hpp:2704:68: error: forming reference to void typename Graph::vertex_descriptor,const Property, Tag> const_type; ^ error: command 'gcc' failed with exit status 1 Makefile:33: recipe for target 'sage' failed make: *** [sage] Error 1 Thank you, Meghana

1 0

Fw: Mysterious Boost.System-related errors when running Beast tests
by Peter Dimov 05 May '18

05 May '18

The story starts with https://travis-ci.org/vinniefalco/beast/jobs/375049193 which gives the error dyld: Symbol not found: __ZN5boost6system6detail19system_category_ncxEv Referenced from: /Users/travis/build/vinniefalco/boost-root/bin.v2/libs/beast/test/beast/core/clang-darwin-4.2.1/debug/threadapi-pthread/threading-multi/fat-tests Expected in: /usr/local/lib/libboost_system.dylib boost::system::detail::system_category_ncx is a new function (in develop), and careful reading of the above reveals that the compiler is trying to link to a preinstalled libboost_system.dylib, in /usr/local/lib. Looking at the log, Boost.System is not even being built. This is odd; the Beast root Jamfile contains <library>/boost/system//boost_system (at https://github.com/boostorg/beast/blob/develop/Jamfile#L78) but even if it didn't, it also links to Filesystem, which _is_ being built, and Filesystem also depends on System in its build/Jamfile: https://github.com/boostorg/filesystem/blob/develop/build/Jamfile.v2#L29 So Boost.System should be built, but it isn't. Its Jamfile hasn't been touched in 10 years: https://github.com/boostorg/system/blob/develop/build/Jamfile.v2 In addition, there's not even a `mklink-or-dir boost/system` in the log, even though the link must be created because the new headers are being used (this could be a separate issue). The Linux/g++ job, https://travis-ci.org/vinniefalco/beast/jobs/375049187, also doesn't seem to build Boost.System, but it works for some reason. When I try `b2 libs/beast/test` on Windows, with msvc-14.1, Boost.System is being built, in the very beginning: ...patience... ...patience... ...patience... ...found 6992 targets... ...updating 1090 targets... link.hardlink ..\..\boost\utility\string_view.hpp Hardlink created for ..\..\boost\utility\string_view.hpp <<===>> ..\utility\include\boost\utility\string_view.hpp compile-c-c++ ..\..\bin.v2\libs\beast\test\beast\core\type_traits.test\msvc-14.1\debug\threadapi-win32\threading-multi\type_traits.obj type_traits.cpp compile-c-c++ ..\..\bin.v2\libs\beast\test\beast\core\type_traits.test\msvc-14.1\debug\threadapi-win32\threading-multi\main.obj main.cpp compile-c-c++ ..\..\bin.v2\libs\system\build\msvc-14.1\debug\threading-multi\error_code.obj error_code.cpp msvc.link.dll ..\..\bin.v2\libs\system\build\msvc-14.1\debug\threading-multi\boost_system-vc141-mt-gd-x32-1_66.dll (The 1.66 version instead of 1.68 was caused by a typo in the superproject which is now fixed.) When I try the same on Ubuntu Trusty, the result is the same as on Travis; no `mklink-or-dir boost/system`, no building of Boost.System, yet everything compiles and works, and I don't have a preinstalled Boost on my VM. It makes no sense at all. Does anyone have any ideas what might be happening here?

1 1

[release][website] Help wanted
by Daniel James 01 May '18

01 May '18

Hello all, For the last couple of releases, I've been handling the releases mostly on my own, but I'm starting a new job and I'm going to have a lot less time, or maybe even no time, for Boost. So we really need more people helping with release management and updating the website. The main release manager responsibilities are described here: https://svn.boost.org/trac10/wiki/ReleasePractices/ManagerCheckList It's probably best if there are a few people involved. I don't think all of them will need admin permissions. For updating the website, you mainly need to occasionally edit html/quickbook files, accept pull requests to the release notes, and use the php scripts to updates the site at release time (I should be able to help a little there). thanks, Daniel

6 5

Showstopper: Build broken on predef module
by Vicente J. Botet Escriba 30 Apr '18

30 Apr '18

Hi Rene, I've needed -to update to the last boost version and I'm experimenting the same issue as the one reported in https://github.com/boostorg/build/issues/299 but in my Mac. /Users/viboes/github/m_boost/libs/predef/check/../tools/check/predef.jam:46: Unescaped special character in argument $(language)::$(expression) /Users/viboes/github/m_boost/tools/build/src/build/configure.jam:288: in try-find-build *** argument error * rule log-check-result ( result ) * called with: ( ) * missing argument result Do you have an idea of what is wrong? Best, Vicente

3 5

Need help with adding tests
by fady esam 30 Apr '18

30 Apr '18

Hi, i was working on a new opencl api for ublas and i need to add the tests and benchmarks to the ublas library. Amy help would be appreciated :) I am adding my file to the test-suite numeric/uBLAS but i want to add include directories and link 2 libraries with compiling the code.. Can anybody help me with that? Thanks in advance

1 0

[doc] Libraries Listed by C++ standard
by Mateusz Loskot 27 Apr '18

27 Apr '18

Hi, Since each Boost library seems/is free to decide about which C++ standard they require, would it be useful to start tagging each library with standard in the release notes and docs? Perhaps new "by by C++ standard" listing could be added in here https://www.boost.org/libs/ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

5 8

[GSoC] My proposal with Boost C++ was accepted!!
by Laouen Belloli 27 Apr '18

27 Apr '18

Hi, Boost community, I was notified some days ago that my proposal for the Boost.Real project was accepted in the Google Summer of Code 2018 program. I'm currently in contact with my mentor (Damian Vicino) talking about how to start the project and how to properly work to get a clean and performant code. Any suggestion about common working methodologies in boost projects are welcome, and if there is a tutorial on the boost programming style please let me know so I can achieve a cleaner coding style that fits better with the rest of the library projects and facilitate the review process. Regarding where to store the project: I have received an invitation to join the BoostGSoC18 GitHub organization from David Bellot. Is this a good place where to create the Boost.Real project? I suppose that the organization was created for this purpose, but because I only got the invitation I don't want to create my project within the organization without asking first. Best, -- Laouen Mayal Louan Belloli. LIAA - DC - FCEyN - UBA. C.A.B.A. - Buenos Aires - Argentina. https://liaa.dc.uba.ar +54 9 11 38675694

2 1

[config] Macro for "using" type alias defects
by Raffi Enficiaud 26 Apr '18

26 Apr '18

Hi all, I was wondering if there is any macro in Boost.Config for advertising the defect of the "using" support from the compiler. I was reported this: https://github.com/boostorg/test/pull/140 and at the time I wrote the thing, I thought that those guards would have been enough: https://github.com/boostorg/test/blob/35c9acf5bd38d625ebd45cf940c5b9a19aa22… (auto, tuple and variadic template sounds to me more difficult to support than "using" template alias). Would it make sense to have BOOST_NO_CXX11_TYPE_ALIAS? Thanks, Raffi

3 7

Boost issue or no?
by Joshua Alexander 26 Apr '18

26 Apr '18

Hi all, I am trying to build pCloudCC and not sure if this is a Boost issue or a pCloud issue: # make [ 10%] Building C object CMakeFiles/sqlite3.dir/lib/sqlite/sqlite3.c.o [ 20%] *Linking C static library libsqlite3.a* [ 20%] Built target sqlite3 [ 30%] Building CXX object CMakeFiles/pcloudcc_lib.dir/pclsync_lib_c.cpp.o [ 40%] Building CXX object CMakeFiles/pcloudcc_lib.dir/pclsync_lib.cpp.o In file included from */root/build/console-client-master/pCloudCC/pclsync_lib.cpp:30:0*: */root/build/console-client-master/pCloudCC/lib/pclsync/pcompat.h:95:0:* *warning:*"_GNU_SOURCE" redefined [enabled by default] #define _GNU_SOURCE * ^* *<command-line>:0:0:* *note: *this is the location of the previous definition In file included from */usr/local/include/boost/smart_ptr/detail/local_sp_deleter.hpp:20:0*, from */usr/local/include/boost/smart_ptr/shared_ptr.hpp:1158*, from */usr/local/include/boost/shared_ptr.hpp:17*, from */root/build/console-client-master/pCloudCC/pclsync_lib.cpp:45*: */usr/local/include/boost/smart_ptr/detail/local_counted_base.hpp:* In member function ‘*void boost::detail::local_counted_base::add_ref()*’: */usr/local/include/boost/smart_ptr/detail/local_counted_base.hpp:67:49:* *error: **__builtin_assume*’ was not declared in this scope __builtin_assume( local_use_count_ >= 1 ); * ^* In file included from */usr/local/include/boost/smart_ptr/detail/sp_counted_impl.hpp:29:0*, from */usr/local/include/boost/smart_ptr/detail/shared_count.hpp:30*, from */usr/local/include/boost/smart_ptr/shared_ptr.hpp:28* , from */usr/local/include/boost/shared_ptr.hpp:17*, from */root/build/console-client-master/pCloudCC/pclsync_lib.cpp:45*: /usr/local/include/boost/core/addressof.hpp: In instantiation of ‘*T* boost::addressof(T&) [with T = int (*)(_IO_FILE*)]*’: */usr/local/include/boost/smart_ptr/detail/sp_counted_impl.hpp:182:98:* required from ‘*void* boost::detail::sp_counted_impl_pd<P, D>::get_local_deleter(const sp_typeinfo&) [with P = _IO_FILE*; D = int (*)(_IO_FILE*); boost::detail::sp_typeinfo = std::type_info]*’ */root/build/console-client-master/pCloudCC/pclsync_lib.cpp:304:1:* required from here */usr/local/include/boost/core/addressof.hpp:40:33:* *error: *‘ *__builtin_addressof*’ was not declared in this scope return __builtin_addressof(o); * ^* make[2]: *** [CMakeFiles/pcloudcc_lib.dir/pclsync_lib.cpp.o] Error 1 make[1]: *** [CMakeFiles/pcloudcc_lib.dir/all] Error 2 make: *** [all] Error 2

2 4