- Boost - lists.preview.boost.org

explicit-failures-markup.xml
by Niall Douglas 30 Jan '19

30 Jan '19

I'm trying to tell the Boost regression matrix that GCC 8 failures are to be expected using explicit-failures-markup.xml, but it seems to not be working: https://www.boost.org/development/tests/master/developer/outcome.html Here is my explicit-failures-markup.xml: <?xml version="1.0" encoding="utf-8"?> <explicit-failures-markup>  <library name="outcome"> <mark-unusable> <toolset name="clang-linux-3*"/> <toolset name="gcc-3*"/> <toolset name="gcc-4*"/> <toolset name="gcc-5*"/> <toolset name="gcc-mngw-3*"/> <toolset name="gcc-mngw-4*"/> <toolset name="gcc-mngw-5*"/> <toolset name="msvc-7*"/> <toolset name="msvc-8*"/> <toolset name="msvc-9*"/> <toolset name="msvc-10*"/> <toolset name="msvc-11*"/> <toolset name="msvc-12*"/> <toolset name="msvc-13*"/> <toolset name="msvc-14.0.*"/> <note author="Niall Douglas">Complete C++14 support is the minimum requirement.</note> </mark-unusable> <mark-expected-failures> <toolset name="gcc-8*"/> <note author="Niall Douglas">GCC 8 currently ICEs with Outcome's unit tests in C++ 17 or later.</note> </mark-expected-failures> </library> </explicit-failures-markup> What am I doing wrong? Thanks, Niall

2 2

[lexical_cast] Assumed internal double conversion of float?
by Brian Kuhl 30 Jan '19

30 Jan '19

Hi Boost experts, We are chasing down some test failures with floats on VxWorks using the Dinkum clib and c++lib. We are testing with clang on Intel and Arm targets and GCC on PowerPC targets. An example failure at the bottom of this email. We have determined that boost::detail::lcast_get_precision<float>() is returning 9, well in access of the defined FLT_DIG of 6, or the practical float limit of 6.92. Specifically this code here: bool shl_real_type(float val, char* begin) { using namespace std; const double val_as_double = val; finish = start + #if defined(_MSC_VER) && (_MSC_VER >= 1400) && !defined(__SGI_STL_PORT) && !defined(_STLPORT_VERSION) sprintf_s(begin, CharacterBufferSize, #else sprintf(begin, #endif "%.*g", static_cast<int>(boost::detail::lcast_get_precision<float>()), val_as_double); return finish > start; } Where does boost::detail::lcast_get_precision<float>() come from, and why is it 9 ? Is it perhaps assuming some intermediate double conversion internally? In Dinkum's C library, Plager conservatively does not promote to a double, when converting to a string. Many thanks, Brian Wind River ->cmd "LD_LIBRARY_PATH=/opt/TestTriggerLocalPath/Workspace/vx7-boost/2019-01-13/vsb/app/boost/fsl_imx6_llvm_up_32_vxWorks/usr/root/llvm/bin;/opt/TestTriggerLocalPath/Workspace/vx7-boost/2019-01-13/vsb/app/boost/fsl_imx6_llvm_up_32_vxWorks/usr/lib/common" [vxWorks *]# cd /opt/TestTriggerLocalPath/Workspace/vx7-boost/2019-01-13/vsb/app/boost/fsl_imx6_llvm_up_32_vxWorks/3pp/BOOST/boost_1_68_0/status [vxWorks *]# run -x -t 0x01000000 -u 100000 -- ../bin.v2/libs/lexical_cast/test/lexical_cast_float_types_test.test/clang-vxworks/debug/cross-compile-vxworks/static-only-on/lexical_cast_float_types_test.vxe Launching process '../bin.v2/libs/lexical_cast/test/lexical_cast_float_types_test.test/clang-vxworks/debug/cross-compile-vxworks/static-only-on/lexical_cast_float_types_test.vxe' ... Process '../bin.v2/libs/lexical_cast/test/lexical_cast_float_types_test.test/clang-vxworks/debug/cross-compile-vxworks/static-only-on/lexical_cast_float_types_test.vxe' (process Id = 0x20482f10) launched. Running 3 test cases... unknown location(0): [4;31;49mfatal error: in "lexical_cast float types unit test/test_conversion_from_to_double": boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_lexical_cast> >: bad lexical cast: source type value could not be interpreted as target [0;39;49m ../libs/lexical_cast/test/lexical_cast_float_types_test.cpp(299): [1;36;49mlast checkpoint [0;39;49m unknown location(0): [4;31;49mfatal error: in "lexical_cast float types unit test/test_conversion_from_to_long_double": boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_lexical_cast> >: bad lexical cast: source type value could not be interpreted as target [0;39;49m ../libs/lexical_cast/test/lexical_cast_float_types_test.cpp(299): [1;36;49mlast checkpoint [0;39;49m

4 3

GSoC 19
by Sandesh Ghanta 30 Jan '19

30 Jan '19

Hey All, I am Sandesh Ghanta, a junior majoring in Computer Science and Engineering. I am interested in contributing to boost and would also like to work with boost in GSoC 19. I am good with C, C++, data structures, algorithms and am currently trying to fix some issues in boost. As I am a beginner to boost I am currently confused as to what project to contribute to, I have been looking at the various issues available to see what I am interested in, but it would be really helpful if someone could guide me. Yours Sincerely, Sandesh Ghanta, FOSS@Amrita <http://amfoss.in> GitHub <https://github.com/sandeshghanta> | Codechef | <http://www.codechef.com/users/sandeshghanta>Codeforces <http://www.codeforces.com/profile/sandeshghanta>

1 0

[gsoc2019] Searching for student
by Damian Vicino 30 Jan '19

30 Jan '19

Hi, I would like to mentor again this year. Some projects I'm particularly interested are getting safefloat or real ready for a formal review (both projects are from previous years and near completion). I'm also open to other projects too. Just ping me with an idea of what you would like to do. Best regards, Damian

1 0

LEAF has been refactored, it now has a much simplified error handling interface
by Emil Dotchevski 29 Jan '19

29 Jan '19

LEAF is a C++11 error handling library for use in low-latency environments. I'm looking for a Boost Review Manager. Any one of you good people willing to volunteer? :) https://zajo.github.io/leaf/ Features: -Header-only, no dependencies. - No dynamic memory allocations. - Any error-related object of any movable type is efficiently delivered to the correct error handler. - Compatible with std::error_code, errno and any other error code type. - Support for multi-thread programming. - Can be used with or without exception handling.

4 10

Wanted to contribute in your projects
by Jibran Zia 29 Jan '19

29 Jan '19

Hello I am Jibran Zia studying in National University of Information and Technology. I wanted to contribute in your projects for 2019 Google summer of Code. Please give me general overview about how I start working and from where I get code of your projects and how I will contribute in it... Thank you so much

2 1

GSOC 19
by Amit Singh 29 Jan '19

29 Jan '19

Hi Sir/Ma'am, My name is Amit Singh and I'm 2nd year CS student. 1. Extending GSoC 18 boost stats idea with regression model and tools for statistics. 2. Expression solver 3.Some features of functional programming similar to transform in c++ which could help programmer to apply functions to whole matrix or vector or transform the data.

1 0

Re: [boost] [histogram] discussion of accessor interface design
by Bjorn Reese 28 Jan '19

28 Jan '19

On 1/15/19 12:35 PM, Hans Dembinski via Boost wrote: > Pros: > - really terse > - you can access methods on the pointee with x->method() as well! (useful when histogram counters are not PODs) > - you can iterate over x to get the indices, for (auto i : x) { … } works Doesn't range-for use operator* so you will get the values? > - since x acts like an array to the indices, you can pass it to functions which accept ranges or iterators (it has .begin() and .end()) > - x can be (and is) enhanced with other useful methods > * x.bin(N) returns the current bin interval for the N-th axis, allowing you to access the central value, width, edges > * x.density() returns the current density (bin value divided by product of current bin widths) > Cons: > - *x and x[0] do completely different things: *x gives you the bin value, x[0] gives you the first index An alternative is to rename x[i] to x.index(i).

2 1

UBSan question
by Raffi Enficiaud 25 Jan '19

25 Jan '19

Hi, I am trying to correct for the errors reported by UBSAN in boost.test. A lot of them were false positive, as ... in boost.test, we check the capacity of the framework to catch various errors in the program. I compile/run the tests with the following: ../../../b2 \ --toolset=clang \ cxxflags=-std=c++11 \ cxxflags=-fno-omit-frame-pointer \ cxxflags=-fsanitize=undefined \ cxxflags=-fno-sanitize-recover=undefined \ cxxflags=-fsanitize-recover=integer-divide-by-zero \ cxxflags=-fsanitize-recover=float-divide-by-zero \ linkflags=-fsanitize=undefined \ linkflags=-fno-sanitize-recover=undefined \ linkflags=-fsanitize-recover=integer-divide-by-zero \ linkflags=-fsanitize-recover=float-divide-by-zero \ linkflags=-fuse-ld=gold \ variant=debug I have an exception that is failing the tests on clang-6/ubuntu18.04 (UBSAN exiting the process), but not on gcc-8/ubuntu18.04 (full log below). UndefinedBehaviorSanitizer:DEADLYSIGNAL ==8303==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address This FPE is happening for instance after reading from a null pointer. I've searched on how to silence/blacklist this, but none of the approaches worked so far, and I am not sure what is provoking this FPE. Is there any UBsan specialist? Does anyone have an idea? Thanks, Raffi clang-linux.compile.c++.without-pch ../../../bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/prg_exec_monitor-ts/system-exception-test.o clang-linux.link ../../../bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test testing.capture-output ../../../bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test.run ====== BEGIN OUTPUT ====== prg_exec_monitor-ts/system-exception-test.cpp:38:15: runtime error: division by zero #0 0x42d03f (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42d03f) #1 0x42f344 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42f344) #2 0x42e8b1 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42e8b1) #3 0x43dafa (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x43dafa) #4 0x43a6f2 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x43a6f2) #5 0x436d13 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x436d13) #6 0x43726f (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x43726f) #7 0x42d148 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42d148) #8 0x42e216 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42e216) #9 0x7f648e20fb96 (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) #10 0x405859 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x405859) UndefinedBehaviorSanitizer:DEADLYSIGNAL ==8303==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address 0x00000042d049 (pc 0x00000042d049 bp 0x7ffe501ec660 sp 0x7ffe501ec630 T8303) #0 0x42d048 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42d048) #1 0x42f344 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42f344) #2 0x42e8b1 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42e8b1) #3 0x43dafa (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x43dafa) #4 0x43a6f2 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x43a6f2) #5 0x436d13 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x436d13) #6 0x43726f (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x43726f) #7 0x42d148 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42d148) #8 0x42e216 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42e216) #9 0x7f648e20fb96 (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) #10 0x405859 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x405859) UndefinedBehaviorSanitizer can not provide additional info. ==8303==ABORTING EXIT STATUS: 1 ====== END OUTPUT ====== (failed-as-expected) ../../../bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test.run

3 7

Any interest in Compile Time Hash Containers library?
by Ivan Matek 25 Jan '19

25 Jan '19

Hi everybody, my first message, I hope I do not mess this up. I was contemplating writing a Compile Time Hash Containers library and I wrote a test implementation for sets and benchmarked it against mostly ska:: sets since they are the best. Document is here: https://docs.google.com/document/d/1IsUiWl3K0h2pgttYgMt67CxgJ3zeXBKZEA7hvAQ… It is quite long, but it aims to provide a introduction to the problem for people unfamiliar with details of hashing, and also it goes into a lot of discussions, if you care just about the numbers you can skip the "boring parts". My interpretation of benchmarks is that it performs very well in some cases, decently in others, but I am biased. :) Code is not available online since I do not want to dump a test project online without extensive documentation, but if somebody has a problem that may be benefited by this test implementation feel free to let me know, I would be happy to get some real world feedback on prototype. Limitations is that test implementation only works for sets, so no maps and if your objects are not integers you will probably not get much speedup. Also if your set has more than 100ish items GCC will run out of memory and VC++ does not compile code at all, so clang is the only way for most use cases today. One more disclaimer is that I do not want this library to be some beast like ranges that takes years to implement, so if after reading the document you consider implementation quite basic I won't be offended :) In other words I feel that library like this although relatively simple compared to regular Boost libraries can provide quite a lot of benefit for some usecases where people really really care about performance of hash containers where values are known during compile time. I know you can not predict the future of an unimplemented library, but I would be happy with some general feedback, and if you think this library would be nice boost proposal I would be interested in some pointers wrt how to proceed. If somebody wonders how user code looks at the moment: #include "cxhash_set.h" // also could be a result of constexpr function, no need for initializer list static constexpr std::array<int, 20> ints{0,1,2,3,5,8,21,34,64,128,256,512,1024,1701,1729,2048,4096,12345,123456,1234567}; int main() { cxhash_set<ints> ints_set; // contains could(should be?) static, but for now it is "normal" member fn std::cout << std::boolalpha << ints_set.contains(21) << std::endl; std::cout << std::boolalpha << ints_set.contains(22) << std::endl; } P.S. feel free to comment in the google doc, I actually find mailing lists quite limited when it comes to prolonged and or detailed discussions. Maybe we can ping Alexandrescu for an instance of dlang forums, so we get a better discussion tools, and he gets a way to convert us to D. :)

5 7

Status of Boost GSoC 2019?
by Mateusz Loskot 24 Jan '19

24 Jan '19

Hi, (I've asked this David Bellot by email some time ago. No response arrived, so asking here again.) One student asked about GSoC recently [1] but w/o answer. An empty repo for this year has been created. And, the timeline [3] says organizations need to apply by Feb 6. I wonder, what is the status of the preparation for GSoC 2019? [1] https://lists.boost.org/Archives/boost/2019/01/244849.php [2] https://github.com/BoostGSoC19 [3] https://summerofcode.withgoogle.com/how-it-works/ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net <http://mateusz.loskot.net>

1 0

[stacktrace] libbacktrace callback for backtrace_pcinfo invalid return value
by Muazin Mugadr 24 Jan '19

24 Jan '19

Hello all See also: https://stackoverflow.com/questions/54333608/boost-stacktrace-not-demanglin… I am cross compiling boost on Unix for Windows with MINGW. I am using libbacktrace compiled using the same toolchain from here: https://github.com/ianlancetaylor/libbacktrace Digging through the code of libbacktrace I was able to deduce that in a success case the return value of backtrace_pcinfo will be the return value of the callback supplied to that function (for DWARF search). The callback boost is giving looks like this: inline int libbacktrace_full_callback(void *data, uintptr_t /*pc*/, const char *filename, int lineno, const char *function) { pc_data& d = *static_cast<pc_data*>(data); if (d.filename && filename) { *d.filename = filename; } if (d.function && function) { *d.function = function; } d.line = lineno; return 0; } As you can see it will always return 0. This causes an issue with the way the function is called: ::backtrace_pcinfo:( state, reinterpret_cast<uintptr_t>(addr), boost::stacktrace::detail::libbacktrace_full_callback, boost::stacktrace::detail::libbacktrace_error_callback, &data ) || ::backtrace_syminfo:( state, reinterpret_cast<uintptr_t>(addr), boost::stacktrace::detail::libbacktrace_syminfo_callback, boost::stacktrace::detail::libbacktrace_error_callback, &data ); If the symbol is found using backtrace_pcinfo the return value will be 0. If its not found it will be 0. It will always use the value provided by backtrace_syminfo. Is this intended? BR Cromon

1 0

Tests: Runtime type_mismatch after upgrade to 1.69
by Florian Lindner 24 Jan '19

24 Jan '19

Hello, after my distribution rolled out the upgrade to Boost 1.69 I am unable to compile my application anymore. I try to get the log_level set. Minimal compiling example: #define BOOST_TEST_DYN_LINK #include <boost/test/unit_test.hpp> #include <boost/test/unit_test_parameters.hpp> bool init_unit_test() { using namespace boost::unit_test; auto logLevel = runtime_config::get<log_level>(runtime_config::btrt_log_level); return true; } int main(int argc, char* argv[]) { int retCode = boost::unit_test::unit_test_main( &init_unit_test, argc, argv ); return retCode; } which compiles fine g++ -std=c++11 -lboost_unit_test_framework boosttesting.cpp but gives an runtime error: % ./a.out Test setup error: boost::runtime::arg_type_mismatch: Access with invalid type for argument corresponding to parameter log_level Thanks! Florian

1 0

C++Now 2019 Registration is Open
by Jon Kalb 24 Jan '19

24 Jan '19

Boosters, Registration for C++Nows 2019 (aka BoostCon) is now open: http://cppnow.org/announcements/2019/01/2019-registration-is-open/ Please help us to spread the word about this announcement. Thanks. Note that the Aspen Meadows Resort online registration link is also up on the lodging page. Because there will be another group in the hotel, we’ve been allocated fewer rooms this year. Please either reserve a room very soon or plan to stay at the Lamplighter or another hotel in town. See you in Aspen in May. Jon

1 0

[gsoc19][GIL] Project proposal
by Miral Shah 23 Jan '19

23 Jan '19

Hello everyone, I am Miral Shah a computer engineering student from India. I have been talking with Boost.GIL community on GIL's Gitter channel since last few weeks to come up with the new idea for GSoC19. After many suggestions and a long discussion on various ideas with the contributors, we have come up with the idea to expand the GIL by introducing new image processing algorithms into it. I would also like to thank Stefan Seefeld and Mateusz Loskot for their guidance and support. Proposal idea can be found here: https://github.com/boostorg/gil/wiki/GSoC-2019 Thank you, Miral Shah

1 0

Boost log issues and workarounds
by hh h 21 Jan '19

21 Jan '19

Hi, I like the boost log, but there are many small issues, appreciate your kind help: I followed the following link to use a good macro LOG: https://stackoverflow.com/questions/35895199/boost-log-and-severity-local-a… But calling LOG(error) caused much trouble for the name space collision, alternative is to use full namespace boost::log::trivial::error, but that is too cumbersome,I tried to use an uppercase ERROR to replace it in an enum ERROR = boost::log::trivial::error, obviously that could not be complied, although it is defined as enum severity_level in trivial.hpp, it does not look like the boost::log::trivial::error is an enum value. Any workarounds? Another issue from that link is it has to call LOGGABLE prior to call LOG(error) in each function, that makes more clumsy, software developers in my team are not happy about it. Any workaround to have a fixed argument in BOOST_LOG_STREAM_WITH_PARAMS, without need to claim boost::log::sources::severity_logger<boost::log::trivial::severity_level> slg; in each function? You guys are genius that must be a way to do it, appreciate your advice. Thank you

4 22

[lockfree] wait-free multi-queue?
by Shawn Yarbrough 18 Jan '19

18 Jan '19

Is it practical to have a wait-free, multi-producer/multi-consumer queue? I ask because Boost's Lockfree multi-queue is only advertised as being "lock-free". (Boost does offer a wait-free single-queue.) https://www.boost.org/doc/libs/1_69_0/doc/html/lockfree.html Shawn Y.

2 1

Re: [boost] [parameter] Helping user libraries adjust to recent changes in GitHub develop branch
by Cromwell Enage 17 Jan '19

17 Jan '19

Happy New Year, everyone! > I've been contributing upgrades to Boost.Parameter functionality > and documentation in the GitHub develop branch for the past > couple of months. These upgrades include the addition of code > generation macros for Boost.Parameter-enabled function call > operators and support for perfect forwarding, and more upgrades > are yet to come. It's been an enjoyable experience so far, > but understandably there are some growing pains. I've taken > pains to ensure that as long as user libraries access only the > public interface of Boost.Parameter, they won't be affected by > the changes. However, there are several notable libraries that > currently use non-public portions of Boost.Parameter, so > whenever possible I've submitted PRs to those libraries that > either change the usage to access only public portions > (preferred) or make quick fixes (temporary). Update: As of this writing, I have active PRs for the following libraries: Boost.Accumulators Boost.Convert Boost.Graph Boost.Log AFAIK, these are the libraries most directly affected by the changes. To reiterate: I'm willing to help the library maintainers resolve these issues as quickly as possible. I should be able to answer any questions you have about the changes to Boost.Parameter. Cromwell D. Enage

3 2

[histogram] discussion of accessor interface design
by Hans Dembinski 15 Jan '19

15 Jan '19

Dear all, work on boost.histogram is progressing fast. I am still implementing feedback from the review, simplifying the interface, adding requested features, such as axes that can grow. STL compatibility was further improved, you can now also write to histograms via iterators. The normal iterators make sense when you iterate over a 1D histogram. When you iterate over a multi-dimensional histogram, you also want to know the current multi-dimensional index. After considering many options, and I really thought about this a lot, I went for the following design, which is a bit unusual. Therefore I would appreciate feedback. I think it is great, once you overcome an initial feeling of awkwardness. The accessor class is "polymorphic", it behaves like a pointer to the histogram value, and like an array for the multi-dimensional index. In code, this is how you use it: auto h = make_histogram(…) // make 2D histogram for (auto && x : indexed(h)) { // indexed produces a range of accessors // x is a special accessor type, combining two non-overlapping concepts // - it acts like a pointer to the histogram value // - it acts like an array to the current index std::cout << "current value " << *x << std::endl; // "dereference" to get value std::cout << "current index " << x[0] << " " << x[1] << std::endl; // use subscript operator to get index } This syntax is beautifully terse, e.g. see https://github.com/HDembinski/histogram/blob/develop/examples/guide_access_… for a full example, especially line 66. Pros: - really terse - you can access methods on the pointee with x->method() as well! (useful when histogram counters are not PODs) - you can iterate over x to get the indices, for (auto i : x) { … } works - since x acts like an array to the indices, you can pass it to functions which accept ranges or iterators (it has .begin() and .end()) - x can be (and is) enhanced with other useful methods * x.bin(N) returns the current bin interval for the N-th axis, allowing you to access the central value, width, edges * x.density() returns the current density (bin value divided by product of current bin widths) Cons: - *x and x[0] do completely different things: *x gives you the bin value, x[0] gives you the first index The last point is, of course, where people have a problem. But if you take C++ concepts seriously then the accessor is a perfect model of a pointer and a perfect model of an array. These two roles are non-overlapping and they have non-overlapping sets of interfaces, which I exploit here. If you have the expectation that *x and x[0] should do the same thing, it is so because of C. C has no extensive type system like C++ and does not distinguish between arrays and pointers, although these are very different concepts. A pointer points to a value, and an array is a collection of values. "dereferencing" a collection of values makes no sense, we are just used to it because of our C heritage. C++ has a better type system, and better classes for pointers and arrays than raw pointers. The stdlib authors recognize that *x has no meaning when x is a sequence of values. *x fails when x is a std::vector, std::deque, std::list, or any kind of collection in the stdlib. Even for std::unique_ptr, they made sure that the interfaces for the pointer-to-object and pointer-to-array specializations behave differently: ``` #include <memory> int main() { std::unique_ptr<int> p(new int); // pointer version // p[0]; // fails *p; // OK std::unique_ptr<int[]> a(new int[3]); // array version // *a; // fails a[0]; // OK } ``` Once you accept that the two concepts of pointers and arrays have non-overlapping interfaces in C++, it becomes possible to make a combined object which has both interfaces, and uses these two sets to return different information. If you have read this far, I hope your initial reaction of "woah, this looks really inconsistent and confusing!" turned to "hmm, maybe it is not inconsistent after all". I am looking forward to hear your thoughts. Best regards, Hans PS: The alternative would be to return a std::pair<index_type, value_reference_type>, but this has disadvantages. Unpacking the pair is going be nice in C++17 with structured bindings, but not so much in C++14. Also, it prevents me from adding convenience methods, like the above-mentioned bin(N) and density() methods.

1 0

boost log to concatenate just one log file
by hh h 15 Jan '19

15 Jan '19

Hi, I added boost::log::keywords::open_mode = std::ios_base::app to the log configuration, but it did not stop log file proliferation, every time I started the program, it created a new log file mylog.log0000x, how can I stop creating new logs? Thank you.

2 2

Is it possiable to use a simple LOG(info) in boost log?
by hh h 15 Jan '19

15 Jan '19

Hi, After trying many days on boost log, still have many issues. Google log has a nice LOG(INFO) << "debug";, looks like that kind thing cannot do in boost log, the close online code in https://stackoverflow.com/questions/35895199/boost-log-and-severity-local-a… has to call LOGGABLE first then to use LOG(info) << "my log", it is really cumbersome, is it possible to call LOG(info) like glog? Thank you.

1 1

Boost.Build requirements to exclude GCC 5
by Niall Douglas 14 Jan '19

14 Jan '19

Outcome is now into Boost, and is being tested nightly: Docs in BoostDoc theme: https://www.boost.org/doc/libs/develop/libs/outcome/doc/html/index.html Regression matrix: https://www.boost.org/development/tests/develop/developer/outcome.html One problem is how to exclude from testing GCC 5 which Outcome cannot support due to GCC 5's incorrect parsing of variable templates in nested template classes [1], so I need some sort of Boost.Build project requirement which explicitly excludes GCC 5. Unfortunately, GCC 5 appears to Boost.Config as fully implementing C++ 14, so this is not straightforward. What might work is to specify a requirement for one of the library items at https://github.com/boostorg/config/blob/develop/checks/Jamfile.v2 which we know for a fact libstdc++ 5 does not implement, but libstdc++ 6 does. However, clang with libstdc++ 5 would then be excluded incorrectly, as clang does not have this parsing bug. I guess ideally speaking Boost.Config gains a new test testing for this specific compiler parsing bug. But it seems a bit much to ask for this just for Outcome. Guidance is sought! Niall [1]: https://www.boost.org/development/tests/develop/developer/output/teeks99-02…

4 5

C++Now 2019 Submission Deadline
by Jon Kalb 14 Jan '19

14 Jan '19

The deadline for submitting to C++Now 2019 is just a few days away. If you’ve been thinking of submitting, please do not delay: http://cppnow.org/announcements/2018/12/2019-call-for-submissions/ <http://cppnow.org/announcements/2018/12/2019-call-for-submissions/> Thanks. Jon

1 0

High number of integer_sequence/index_sequence implementations
by Nikita Kniazev 14 Jan '19

14 Jan '19

Bunch of Boost libraries have their own integer_sequence/index_sequence implementation. Wouldn’t it be better if there was boost::integer_sequence/boost::index_sequence? boost\beast\core\detail\integer_sequence.hpp boost\callable_traits\detail\polyfills\make_index_sequence.hpp boost\context\detail\index_sequence.hpp boost\fusion\support\detail\index_sequence.hpp boost\mp11\integer_sequence.hpp boost\phoenix\core\detail\index_sequence.hpp (alias of fusion one) boost\poly_collection\detail\functional.hpp (uses mp11 one) boost\test\data\index_sequence.hpp boost\variant\detail\multivisitors_cpp11_based.hpp

4 4

(no subject)
by Siddhartha Sen 14 Jan '19

14 Jan '19

Hey, This is Siddhartha. I have been interested in contributing to boost and hopefully work with boost in GSOC 2019. I apologise for the delay as my exams were going on and I hope it is not too late to start. I have looked in to the ideas list as well as last year's projects. Currently, I am proficient in c and c++,especially algorithms,data structures and maths. Any help regarding how to get started would be appreciated. I myself have some ideas about implementation of a few libraries which I would like to discuss as well. Thank You

1 0

Regression matrix stopped updating
by Nikita Kniazev 13 Jan '19

13 Jan '19

For past month or two regression matrix update frequency was fluctuating in a big range, sometimes not updating for two-three days. As for now master is not updated for 7 days and develop for 5 days. https://www.boost.org/development/tests/master/developer/summary.html Summary: Master Report Time: Tue, 11 Dec 2018 01:44:54 +0000 https://www.boost.org/development/tests/develop/developer/summary.html Summary: Develop Report Time: Thu, 13 Dec 2018 06:05:04 +0000 Is it down for maintenance or what is going on?

6 8

Safe numerics at Meeting C++
by Robert Ramey 12 Jan '19

12 Jan '19

News Flash for both of you interested in the Boost Safe Numerics Library. Checkout https://www.youtube.com/watch?time_continue=942&v=tcyb1lpEHm0 at 1 hour in. The whole rest of the talk is about a safe integer implementation written D. He uses it to illustrate his concept of "Introspective Programming". ALL the features and techniques he mentions (and more) are implemented in the safe numerics library. The Safe Numerics library is the Next Big thing! Robert Ramey

1 0

question/guidence regarding merge to master
by Robert Ramey 12 Jan '19

12 Jan '19

I'm looking to merge my develop branch into the master so that they will be in sync. I'm thinking that this the changed in develop should be squashed so that the master branch doesn't included all the the intermediate changes made during the develop phase. Is there any boost rule/practice/guidence regarding this?. Ideally, I'd like to see the master have only one set of consolidated changes for each release. But I'm not the person who decides these things or does the work. Any insight by other parties would be appreciated. Robert Ramey

10 29

Re: [boost] A class for embedded friendly callbacks.
by Bjorn Reese 12 Jan '19

12 Jan '19

On 1/4/19 1:30 PM, Mikael Rosbacke via Boost wrote: > I'm Mikael Rosbacke and new to this list. The last couple of months I've > been writing on a class for storing callbacks to different forms of > callables (member functions, functors, free functions). The main focus A while back, a somewhat similar library underwent a formal review. You may want to read the review report to see if any of the comments applies to your library: https://lists.boost.org/boost-announce/2016/12/0484.php

1 0

Re: [boost] Feedback desired for reflective enum library
by Nir Friedman 12 Jan '19

12 Jan '19

I had to fill in the subject for this manually, because of settings for the mailing list. I really hope it ends up on the right thread. Apologies if it doesn't. Hi Geert, There is an ADAPT macro, which is similar to your concept of CONVERT_TO_WISE_ENUM. However, it does require listing the enumerators; after all there's no way to find them out after the fact or else this library wouldn't exist in the first place. That said, I'm not quite sure what you mean by "changing your whole codebase". To take advantage of wise enums, all you'd need to do is change the original enum declaration to the wise enum macro. Everything else in your codebase will continue to work exactly as before. No typedef shenangians are necessary. Changing the original enum declaration is exactly the same amount of work as writing an adapt macro, but you don't have to maintain the list of enumerators twice. So I can't imagine a reason to write things the way you have (unless you want a conditional build dependency on WISE_ENUM but that seems unnecessary). The ADAPT macro is designed to be use wise_enum functionality generically with enumerators whose source you don't control, and therefore cannot change the declaration. Hope that clarifies things. Cheers, Nir

1 0

boost log to display source code name and lines
by hh h 11 Jan '19

11 Jan '19

Hi, I am looking for good log library to replace google log, my plan is to use boost log, but I am not sure if it is mature or it has been used seriously. It lacks some simple basic features such as display source code name and lines in log file, I've searched on line discussion, there are many suggestion to fix it in piece of code, but I could not get that work, difficult to use it may be overstated. Are there any good examples to display source program name and lines similar to asio socket examples on line? What is your opinion about boost log? Should I still pursue it? Thank you. - jhh

3 10

GSoC19
by Pranam Lashkari 10 Jan '19

10 Jan '19

Hello, Organization application date is going to start soon. I was trying to find our idea page for this year but couldn't find it. can anyone help!? Thank you, Pranam Lashkari

1 0

Requesting formal review for (Boost) LEAF
by Emil Dotchevski 10 Jan '19

10 Jan '19

LEAF is a small C++11 error handling library (the acronym stands for Low-latency Error Augmentation Framework). Features: - Header-only, NO dependencies. - No dynamic memory allocations. - Associate objects of arbitrary types with any failure — when it is initially reported or at a later time. - Compatible with std::error_code, errno and any other error handling API. - Use with or without exception handling. - Support for multi-thread programming. Official documentation: https://zajo.github.io/leaf. LEAF is designed for use in low-latency environments without exception handling, but it also works with exception handling; in that case it is a better, more optimal replacement for Boost Exception. This link can be helpful for refactoring existing Boost Exception code: https://zajo.github.io/leaf/#boost_exception.

5 9

async_read SEGFAULT
by hh h 09 Jan '19

09 Jan '19

I use one io_service in one process to run two servers A and B each has its own port, own context and SSL configuration to accept inbound connections. Although both A and B have boost::asio::deadline_timer, but I think there is only one thread is running: (gdb) info threads Id Target Id Frame * 1 Thread 0x7ffff7fe0bc0 (LWP 31204) "ssl_connection" 0x00007ffff4a690a3 in __epoll_wait_nocancel () at ../sysdeps/unix/syscall-template.S:84 The problem I got: - If I started only one server A, it worked just fine for both async_read and async_write. - If I started both servers A and B, even B was in idle, server A could sometime be crashed after receiving and responding just one message, then crashed at next async_read in the first second, it was more stable if it did not call async_write. SEGFAULT: Fault address=0x55b3700d00cf, #4 0x000055555557f98a in boost::asio::detail::task_io_service_operation::complete (this=0x55555584adc0, owner=..., ec=..., bytes_transferred=0) at /usr/include/boost/asio/detail/task_io_service_operation.hpp:38 #5 0x0000555555581f82 in boost::asio::detail::task_io_service::do_run_one ( this=0x555555814710, lock=..., this_thread=..., ec=...) at /usr/include/boost/asio/detail/impl/task_io_service.ipp:372 #6 0x0000555555581ab4 in boost::asio::detail::task_io_service::run ( this=0x555555814710, ec=...) at /usr/include/boost/asio/detail/impl/task_io_service.ipp:149 #7 0x000055555558221f in boost::asio::io_service::run (this=0x7fffffffe150) at /usr/include/boost/asio/impl/io_service.ipp:59 It seems that async_write and async_read messed up, but that problem was intermittent, especially when the server A passed first second, it could be running for hours for doing consequent many async_read and async_write simultaneously. It was only one thread, what could cause that problem? Thank you.

2 11

b2 --exec-prefix=...
by Peter Dimov 09 Jan '19

09 Jan '19

Our "b2 --help" documentation says --exec-prefix=<EPREFIX> Install architecture dependent files here. Default: <PREFIX> --libdir=<LIBDIR> Install library files here. Default: <EPREFIX>/lib and bootstrap.sh also supports --exec-prefix and when given, records it in project-config.jam. But it doesn't work and has never worked. Only --prefix is honored, --exec-prefix is simply ignored. I think that we should bring the documentation and the actual behavior in sync, either by making --exec-prefix work as documented, or removing it from the documentation. Which one should we do? Comments?

5 4

Boost wiki - revised Boost guidance for authors on Warnings - RFC
by Paul A. Bristow 08 Jan '19

08 Jan '19

As promised at the end of a long (hijacked!) thread on 'Warnings' http://boost.2283326.n4.nabble.com/Current-Guidance-on-Compiler-Warnings-td… starting from a query by Brian Kuhl of Wind River on Boost's policy on compiler warnings, I have spent some time revising the previous guidance document on Trac that I edited many years ago. This was a long and tedious task as Markdown, as most conveniently used on Github, is rather different from the mark-up language on Trac, leaving me slightly in fumble mode :-( I have made some updates en passant, but there is still much to do updating for the much improved granularity of warning suppression and perhaps more about other code improvement tools like Lint, UBSan. The overall structure leaves a lot to be desired, but I don't want to put any more work into this without some encouragement that it will prove useful. I have posted the result of my efforts on https://github.com/boostorg/boost/wiki/Guidelines:-Warnings and I am as promised I am starting this new thread on warning for your comments, corrections, condemnations etc. HTH Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

3 2

[cmake] Pull request announcement - update
by mike.dev＠gmx.de 07 Jan '19

07 Jan '19

I think it is time for an update on this issue. #################################################### # TLDR: There are now ~25 boost libraries that can be directly used in a cmake project via the add_subdirectory & target_link_library - workflow. And I want to encourage library maintainers to comment/merge outstanding PRs or make similar additions to their libraries themselves. ################################################### # A summary what that thread was about: In September last year I was informing the mailing list that I was about to make a bunch of PRs adding a set of minimal CMake files to various boost libraries. Their sole purpose was to enable the following workflow from within a cmake project: add_subdirectory( <path-to-boost-libfoo-directory> ) target_link_library( my_app Boost::libfoo ) Without needing b2 or the boost super project for that matter (although support in the super project would be very welcomed) For that, the cmake file in libfoo has to - provide the target Boost::libfoo - attach the dependency information for Boost::libfoo - attach the proper include directory for Boost::libfoo - if necessary, build libfoo with whatever toolchain and compile flags the parent cmake project defines - if necessary, attach any necessary compile definitions to Boost::libfoo Although things like running the unit-tests or provide and install target can be added by any library maintainer (and some have done just that) it is not part of my PRs. ################################################### # What is the current state. For a quick overview, I uploaded a picture of the boost dependency graph (code based on boostdep) that shows which libraries Have a cmake file in their root and which don't [1]. So far, about 25 libraries have gained cmake files as part of this effort (not all from me). And of course there are a couple of libraries that Already used cmake before I started my efforts, but AFAIK, most of them can not be used in the above mentioned work-flow. Of course, there remains a lot to do, but at least progress is happening and we now have fitted almost all "foundational" libraries , so from here on out, the pace should increase. Currently, I have 7 outstanding PRs and I would ask the Respective maintainers to comment on them as soon as they can find some spare time, as further PRs are blocked on them. Even if the PRs get completely rejected, I at least know for which part of boost I should no longer pursue this quest and/or find a workaround. Finally a big thanks to all maintainers that added such cmake files on their own. Best Mike [1] https://gist.github.com/Mike-Devel/46d04409d6ae6053861706e3ad91e4dc Explanation for the linked picture: It shows the boost dependency graph (generating code based on boostdep). - Green libs already have a cmake file in their root directory - Yellow libraries don't have such a cmake file, but all their dependencies have one, so one could be added and most likely there is already a PR for that - Red libraries have at least one direct or indirect Dependency that lacks a cmake file, so I consider Them "blocked" for now.

4 3

A class for embedded friendly callbacks.
by Mikael Rosbacke 07 Jan '19

07 Jan '19

Greetings. I'm Mikael Rosbacke and new to this list. The last couple of months I've been writing on a class for storing callbacks to different forms of callables (member functions, functors, free functions). The main focus has been to make it suitable for embedded work with small footprint and dependable exception and heap behavior. The code can be found on github: https://github.com/rosbacke/delegate It has reached a stage where I'm getting sort of 'done'. I feel it could be useful to a wider audience so I would like to get some feedback about if this is suitable for that and if it is worth starting a new branch for possibly adapting it to boost for inclusion in some future version of boost. Any feedback is appreciated. Cheers, --- Mikael Rosbacke

2 2

Should pass boost::asio::io_service by raw pointer or smart pointer?
by hh h 07 Jan '19

07 Jan '19

Hi, In many examples and even implementations, programmers like to pass boost::asio::io_service by raw pointer: MyClass::MyClass(boost::asio::io_service &io_service) : myRawIoService(io_service) {} Will this cause issues to pass raw pointer for large size of classes, should it be replaced by passing smart pointer: MyClass::MyClass(const std::shared_ptr<boost::asio::io_service> &io_service) : myIoService(io_service) {} Thank you.

5 9

Is there interest in an "iofiber" library?
by Vinícius dos Santos Oliveira 06 Jan '19

06 Jan '19

I have written a completion token for Boost.Asio that is a little more advanced than plain ASIO's spawn featuring abstractions such as join(), detach() and even interrupt(). I'd like to know if there is interest in seeing this library merged as part of Boost. https://vinipsmaker.github.io/iofiber/ (there is also a mutex and a semaphore, but these are undocumented as of now and were poorly ported from the previous token supporting abstractions and need rework) Boost.Fiber integration with ASIO is problematic: https://github.com/boostorg/fiber/issues/102#issuecomment-263558882 Default Boost.Asio yield token will do as long as you don't need communication between fibers. When primitive communication is necessary, you can work around it by exploiting the completion token protocol. In fact, after having rolled my own solution, I eventually was made aware of Peter's solution (which he rolled on his own independently) which was incredibly similar to my solution: https://github.com/equalitie/ouinet/blob/a2afaf9932c8a23434d1f0a10be06fc407… If you need anything more advanced such as careful strand integration, join, or interruption API, you'll just have to roll your own token. That's what I end up doing after working around ASIO's token for many months. There was also a recent request by Vinnie to turn Boost.Coroutine 1 deprecation warning off. This separate library would be an alternative (although it is still a far from review-ready). -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

3 4

Re: [boost] Skipping regression builds for unsupported toolsets
by Nikita Kniazev 05 Jan '19

05 Jan '19

> > How can I 'tell' regression builders to skip building GIL > where required C++ version is not supported? Add requirements to you tests Jamfile, something like: import config : requires ; project /boost/gil/test : requirements [ requires cxx11_constexpr cxx11_decltype cxx11_template_aliases cxx11_variadic_templates ] (those checks come from Config library which most likely you are pulling already in your CI builds). I noticed that some libraris specify "std" in libraries.json, for example: > - Any: "std": [ "c++17" ] > - Ratio: "std": [ "proposal" ] > What is the purpose of these? > Is this respected by regression builds? I doubt those do anything. IIUC `libraries.json` is used only for https://www.boost.org/doc/libs/ list generation.

2 1

Skipping regression builds for unsupported toolsets
by Mateusz Loskot 05 Jan '19

05 Jan '19

Hi, The regression builds report unreloved issues for number of libraries: https://www.boost.org/development/tests/develop/developer/issues.html In particular, for Geometry and GIL those issues happen on msvc-8.0. For GIL, specifically, this is due to the fact GIL now requires C++11. How can I 'tell' regression builders to skip building GIL where required C++ version is not supported? I noticed that some libraris specify "std" in libraries.json, for example: - Any: "std": [ "c++17" ] - Ratio: "std": [ "proposal" ] What is the purpose of these? Is this respected by regression builds? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

iround() and itrunc() in Conceptual Requirements for Real Number Types
by Matt Pulver 04 Jan '19

04 Jan '19

Hello, Regarding the page Conceptual Requirements for Real Number Types https://www.boost.org/doc/libs/1_69_0/libs/math/doc/html/math_toolkit/real_… Is it still accurate to list these 2 rows under Standard Library Support Requirements? - iround(cr1) | int - itrunc(cr1) | int The motivation in asking this is two-fold: 1. I don't see either of these functions listed in the Standard Library. Perhaps this is just old documentation, or I am not looking in the right place. Instead, I do find lround() and truncl(). 2. One of the design goals of Boost.Autodiff (WIP) is to satisfy all of the requirements on this page, and these are the only two which I am unable to satisfy for the above reason. If someone were to update this page, or otherwise advise on how to reconcile, it would be appreciated so that the Boost.Autodiff <https://github.com/pulver/autodiff> library could accurately claim to satisfy 100% of Boost's Real Number Type requirements. Best regards, Matt

2 2

Could shared_ptr cause memory leak?
by hh h 04 Jan '19

04 Jan '19

Suppose I have a session object A, the shared_ptr<A> is created and stored in a global connection list after a connection is accepted by async_accept, when the connection is terminated, the reference in connection list is removed, but since A has a member B still holds A reference, that session object is never deleted, is it memory leak? class A : public boost::enable_shared_from_this<A> { public: A(); ~A(); void Start() {b = make_shared<B>(shared_from_this());} void Stop(); private: shared_ptr<B> b; };

3 6

Re: [boost] [multi_index] problem with Travis integration
by Nikita Kniazev 31 Dec '18

31 Dec '18

Aah, you repository has both Travis enabled. Formerly Travis had two separated sites, one (.org) served for open source project and other (.com) for private projects. A while ago they opened .com for open sources and announced that they will merge .org to .com, but actually nothing changed. https://docs.travis-ci.com/user/open-source-on-travis-ci-com/ > Looking closer, there is a duplication. In commit 1af32b3, the "Travis > CI - Branch" link redirects > (indirectly) to > > https://travis-ci.com/boostorg/multi_index/builds/95957238 > > while the "continuous-integration/travis-ci/push" points to > > https://travis-ci.org/boostorg/multi_index/builds/473601408 > > Note the most surprising fact that *the first link is **to travis-ci.com > and the second **to > travis-ci.org*. These two domains don't see each other (If i try to see > 473601408 in > travis-ci.com or 95957238 in travis-ci.org I get a "we couldn't find > that build" screen). > > Joaqu?n M L?pez Mu?oz

2 1

[multi_index] problem with Travis integration
by Joaquin M López Muñoz 30 Dec '18

30 Dec '18

Sorry to be such a noob when it comes to Travis integration, but for the life of me I just can't see how to fix the following: Travis was activated for boostorg/multi_index yesterday, and, in addition, I've been given admin privileges to boostorg/multi_index so I can, in theory, control how the Github/Travis communication happens. Evreything is working OK except that, when I push something to develop, *two* Travis tasks are created, named "Travis CI - Branch"and "continuous-integration/travis-ci/push": whereas in all the other boostorg libs I've examined, only "continuous-integration/travis-ci/push" appears (example with smart_ptr): I've walked all over the settings pages for both Travis and Github, looked up on the Internet and didn't come to any conclusion as to what this "Travis CI - Branch" thing is and how it can be turned off so that integration looks the same way as for any other Boost lib. Any clue much appreciated. Joaquín M López Muñoz

2 3

Re: [boost] [multi_index] problem with Travis integration
by Nikita Kniazev 30 Dec '18

30 Dec '18

This might be connected to GitHub Services deprecation https://developer.github.com/changes/2018-04-25-github-services-deprecation/ https://blog.travis-ci.com/2018-09-27-deprecating-github-commit-status-api-… Sorry to be such a noob when it comes to Travis integration, but for the > life of > me I just can't see how to fix the following: > Travis was activated for boostorg/multi_index yesterday, and, in > addition, I've been given > admin privileges to boostorg/multi_index so I can, in theory, control > how the Github/Travis > communication happens. Evreything is working OK except that, when I push > something to > develop, *two* Travis tasks are created, named "Travis CI - Branch"and > "continuous-integration/travis-ci/push": > whereas in all the other boostorg libs I've examined, only > "continuous-integration/travis-ci/push" appears (example with smart_ptr): > I've walked all over the settings pages for both Travis and Github, > looked up on > the Internet and didn't come to any conclusion as to what this "Travis > CI - Branch" > thing is and how it can be turned off so that integration looks the same > way > as for any other Boost lib. > Any clue much appreciated. > Joaqu?n M L?pez Mu?oz

2 1

[multi_index] Travis/AppVeyor activation request
by Joaquin M López Muñoz 29 Dec '18

29 Dec '18

Hi, Could some administrator with the required permissions activate Travis and AppVeyor integration for boostorg/multi_index? Thank you! Joaquín M López Muñoz

2 2

GSOC 2019
by Amit Singh 28 Dec '18

28 Dec '18

Hi Sir/Ma'am, My name is Amit Singh and I'm 2nd year CS student. I would like extend GSoC 18 boost stats idea with few ML models and tools

1 0

Does async_accept only access connection object raw pointer and wrapped it by shared pointer internally?
by hh h 27 Dec '18

27 Dec '18

I don't like to use raw pointer by new and delete, but the following code will be crashed by double delete, can't async_accept accept shared pointer? std::shared_ptr<session> new_session = std::make_shared<session>(io_service_, context_); acceptor_.async_accept(new_session->socket(), boost::bind(&server::handle_accept, this, new_session.get(), boost::asio::placeholders::error)); Thank you.

3 3

[GSoC-2019] Guidance about GSoC 2019
by Karthik Kothuri 24 Dec '18

24 Dec '18

Hi, I am Karthik Kothuri, a 2nd year Computer Science and Engineering student at National Institute of Technology, Warangal. I would like to contribute to this organization in view of GSoC 2019. Any mentor is requested to guide me regarding this and tell me where to get started. I am experienced with moderate C++ and have been using it extensively for over an year for my Data Structures and Algorithms course. I also have a basic knowledge of object oriented programming which I will improve over the course of the next few months as part my college curriculum. Thanks.

1 0

[uuid] constexpr uuid from string and ""_uuid literal
by Tobias Loew 24 Dec '18

24 Dec '18

Hi, while searching for constexpr GUID from string generators, I found https://gist.github.com/AlexBAV/b58e92d7632bae5d6f5947be455f796f . Since I still work with VS 2015, I wrote a C++11 constexpr version incl. boost-uuid generators. If there's interest adding this to boost uuid, please have a look at https://github.com/tobias-loew/constexpr-GUID-cpp-11 NB. This is not a finished version to be added to uuid. Comments and BOOST-Macros for constexpr needs to be added. Tobias -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

1 0

ASIO TCP socket scalability for large scale connections
by hh h 24 Dec '18

24 Dec '18

Hi, In regard to ASIO TCP socket implementation, for each connections the server needs to open and to maintain a session, obviously there need be adequate RAM and CPU resources for supporting large connections, but does ASIO TCP socket itself has any limitation for connecting to large clients which could be over 10000 or more simultaneously? What will be the maximum connections a single ASIO TCP socket server can handle? Thank you.

3 5

Re: [boost] Should pass boost::asio::io_service by raw pointer or smart pointer?
by Vinnie Falco 24 Dec '18

24 Dec '18

On Thu, Dec 20, 2018 at 6:45 PM Richard Hodges <hodges.r(a)gmail.com> wrote: > ...even with Vinnie's easy to follow guide, it requires a hundred lines of > boilerplate to implement what amounts to one async method. Yes, that is kind of irritating. I've been working on some tools to make it easier. The function wrap_handler returns a new completion handler which wraps your function object (lambda) and inherits the allocator and executor of another completion handler: <https://github.com/vinniefalco/beast/blob/8afbc6090bded0cdfda46871d829ea778…> The class template base_handler<> is meant as a base class for composed operations, it holds the handler for you and it provides all the hooks. I notice that you didn't include an overload for asio_handler_invoke in your example, which will certainly cause undefined behavior in some cases: <https://github.com/vinniefalco/beast/blob/8afbc6090bded0cdfda46871d829ea778…> You can see both wrap_handler and handler_base used together to implement a composed operation, a flavor of async_read_some which has a built-in timeout: <https://github.com/vinniefalco/beast/blob/8afbc6090bded0cdfda46871d829ea778…> In particular, handler_base let me leave out all of the boilerplate which is nice. It is possible that with some adaptation these utilities can be used to achieve the result you desire. These experimental features will appear in Boost.Beast version 1.70.0. Regards

4 7

GitHub testing issues
by Cromwell Enage 22 Dec '18

22 Dec '18

Hi, everyone! Starting yesterday, I experienced failures on all my test builds. Their logs contain the following message: travis_time:end:1a83bdea:start=1545229245463720000,finish=1545229258317024000,duration=12853304000 [0Ktravis_fold:end:install.10 [0Ktravis_fold:start:install.11 [0Ktravis_time:start:04d79bf0 [0K$ ./b2 headers boost-install.jam: No such file or directory Jamroot:307: in boost-install ERROR: rule "boost-install.boost-install" unknown in module "Jamfile</Users/travis/build/CromwellEnage/boost-root>". libs/atomic/build/Jamfile.v2:38: in modules.load /Users/travis/build/CromwellEnage/boost-root/tools/build/src/build/project.jam:372: in load-jamfile /Users/travis/build/CromwellEnage/boost-root/tools/build/src/build/project.jam:64: in load /Users/travis/build/CromwellEnage/boost-root/tools/build/src/build/project.jam:89: in load-used-projects /Users/travis/build/CromwellEnage/boost-root/tools/build/src/build/project.jam:75: in load /Users/travis/build/CromwellEnage/boost-root/tools/build/src/build/project.jam:142: in project.find /Users/travis/build/CromwellEnage/boost-root/tools/build/src/build-system.jam:618: in load /Users/travis/build/CromwellEnage/boost-root/tools/build/src/kernel/modules.jam:295: in import /Users/travis/build/CromwellEnage/boost-root/tools/build/src/kernel/bootstrap.jam:139: in boost-build /Users/travis/build/CromwellEnage/boost-root/boost-build.jam:17: in module scope travis_time:end:04d79bf0:start=1545229258327432000,finish=1545229259660893000,duration=1333461000 [0K [31;1mThe command "./b2 headers" failed and exited with 1 during . [0m It's also happening on Appveyor, and just from looking at < https://github.com/boostorg/graph/pull/144>, I'm not the only one who is encountering these errors. Any help would be appreciated. Thanks! Cromwell D. Enage

7 11

New library proposal: Autodiff
by Matt Pulver 21 Dec '18

21 Dec '18

Hello, An automatic differentiation <https://en.wikipedia.org/wiki/Automatic_differentiation> C++ library - Autodiff - is released under the Boost License and is proposed for inclusion into Boost: - Github: https://github.com/pulver/autodiff - Boost Library Incubator: http://blincubator.com/bi_library/autodiff-2/?gform_post_id=1716 Features: - Instances of autodiff variables satisfy Boost's Conceptual Requirements for Real Number Types <https://www.boost.org/doc/libs/1_69_0/libs/math/doc/html/math_toolkit/real_…>. In fact the class and function template definitions are based upon the tables in this page. - No use of dynamic memory. The only member variable is a std::array<>. - Consistent with Boost's type promotion templates. When adding/multiplying/etc. variables of differing dimension number and sizes, the resulting data type is calculated at compile-time. - Single header-only file. - Intuitive and minimal API. Requirements: - C++17 compiler that supports constexpr if statements. There are a fair amount of calculations done at compile-time which would require messy SFINAE hacks to make this C++14-compatible. Todo: - A github build matrix that also includes clang and MSVC. - Additional documentation, including the mathematics. Feedback and endorsements for Boost Library inclusion are welcome and requested. Best regards, Matt

8 11

[parameter] Helping user libraries adjust to recent changes in GitHub develop branch
by Cromwell Enage 20 Dec '18

20 Dec '18

Hi, everyone! I've been contributing upgrades to Boost.Parameter functionality and documentation in the GitHub develop branch for the past couple of months. These upgrades include the addition of code generation macros for Boost.Parameter-enabled function call operators and support for perfect forwarding, and more upgrades are yet to come. It's been an enjoyable experience so far, but understandably there are some growing pains. I've taken pains to ensure that as long as user libraries access only the public interface of Boost.Parameter, they won't be affected by the changes. However, there are several notable libraries that currently use non-public portions of Boost.Parameter, so whenever possible I've submitted PRs to those libraries that either change the usage to access only public portions (preferred) or make quick fixes (temporary). I'm drawing off Peter Dimov's page < https://pdimov.github.io/boostdep-report/develop/parameter.html> as a guide to focus my efforts. As of this writing, I have active PRs for the following libraries: Boost.Convert Boost.Graph Boost.Lockfree I also have my eye on the following libraries, which I know have been broken by the latest changes: Boost.Accumulators Boost.Log I'm willing to help the library maintainers resolve these issues as quickly as possible. This post can serve as a discussion starting point, and I should be able to answer any questions you have about the changes to Boost.Parameter. Cromwell D. Enage

1 0

Feature/cmake-config merged to develop; yml files need to be updated
by Peter Dimov 19 Dec '18

19 Dec '18

I've just merged the superproject branch feature/cmake-config to develop. This updates `b2 install` to export CMake configuration files into the `cmake` subdirectory of the library directory. These configuration files enable a Boost installation to be used from CMake via `find_package(boost_filesystem)`, without relying on FindBoost. Unfortunately, this change adds two necessary submodules to the superproject, `tools/boost_install` and `libs/headers`. As a result, all .travis.yml and appveyor.yml files that rely on a partial checkout need to be updated to perform git submodule update --init tools/boost_install git submodule update --init libs/headers in addition to the usual git submodule update --init tools/build git submodule update --init libs/config I'm sorry for the inconvenience this will cause, or perhaps already has caused.

5 7

Ignoring unused type aliases in concepts
by Mateusz Loskot 18 Dec '18

18 Dec '18

Hi, In concepts, such unused type aliases are not uncommon. What is the best way to ignore compiler warnings about those? Options I'm aware of are: 1. Adjust compile options in build configuration (Jamfile) 2. Use #pragma in headers 3. Use boost::ignore_unused_variable_warning(alias{}) (or little brother boost::ignore_unused) 4. Ignore ignoring them. The options 1 and 2 are mentioned on https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines The option 3 is not and is there any particular reason why? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

5 16

Error to convert to boost::asio::streambuf to raw buffer char *buffer
by hh h 18 Dec '18

18 Dec '18

boost::asio::streambuf sb; char *raw = sb; error: cannot convert ‘boost::asio::streambuf {aka boost::asio::basic_streambuf<>}’ to ‘char*’ in initialization I've checked the boost::asio::streambuf reference, but could not find anything to fix it, appreciate any clues.

3 3

[cmake] Has the latest effort stalled?
by Andrey Semashev 17 Dec '18

17 Dec '18

Hi everyone, hi Robert, I've been informed[1] that the latest effort to call for CMake submissions and then review them collectively in February has stalled or failed. Is this true? What is the status of this effort, and if it's still on track, what is the current schedule? I'm asking because there is an ongoing effort by Mike-Devel (sorry, don't know your full name) to add minimalistic support for CMake across a number of Boost libraries, including those I maintain, and I've been holding off his submissions until after the review according to Robert's plan. If that plan is no longer in force, I might as well accept Mike's PRs and we (Boost as a whole) might as well accept his solution as the only one we have close to implementation. [1] https://github.com/boostorg/winapi/pull/73#issuecomment-447760554

2 1

Mixing async/sync code thanks to boost::context
by Christophe Bailly 16 Dec '18

16 Dec '18

Hello, I am new in this mailing list, I hope this is the right list to post my issue. Context: I often have to deal with some code which is originally synchronous. When we introduce an asynchronous call, all the callers must be made asynchronous with async/await everywhere. Let's take a concrete example: Suppose we have an existing synchronous library which makes computation. Suppose we can give a custom function to this library to compute a part of the calculation. We decide that this function will call a server... We may wish the main compute function to become asynchronous... Now the big question: Why isn't it possible so far to do this without changing all the functions ?? I find this really ugly, this is really difficult to make a good design. With asymetric async calls, I doubt this is possible, so I tried boost::context. In my example, the "library" is represented by the function calculate which is synchronous. It calls a function call_server which simulates the call to a server, in fact it will just wait for 5 seconds but in a asynchronous way. The main function will do a computation in parallel while the server will be called. You will find the code at the end of the mail. This sounds too good to be true but in this case, where did I miss something ? I haven't implemented a socket with a select but this would work, right ? The library can still be used in an asynchronous or synchronous context (with no extra cost). To help the understanding of the code, we have 3 tasks, the continuation are stored in the tasks vector. task are identified thanks to their indice in the vector: - 0: main task (id_main) - 1: reactor(id_reactor) - 2; computation_task (id_computation) I implement a kind of future, whose value is retrieved at the end of the main function and which launches a task to compute the value. Remarks: 1/ This is not optimised, we could make fewer context switches. There is no need for a specific task for the reactor, it could be called directly. 2/ The call_server function could detect automatically the sync or async context, if the reactor is not active (no waiting tasks to be run), then it would run i a synchronous way. 3/ This solution is based on a singleton for the reactor, but this is what we want, 4/ This could be certainly better coded, I am not an expert, I use to code more in Python and wanted to use C++ to see if I could solve these designs problems. I am curious to read what you think about this, I certainly missed something so please clarify and tell me if a clean solution is possible. Thanks a lot for reading. Regards, Chris #include <boost/lambda/lambda.hpp> #include <iostream> #include <iterator> #include <boost/context/continuation.hpp> #include <iostream> #include <string> #include <vector> #include <tuple> #include <queue> #include <time.h> int a = 0; int result = 0; namespace ctx = boost::context; std::vector<ctx::continuation> tasks; std::queue<int> tasks_to_run; std::vector<int> end_tasks; // list of tasks which ended using clock_info = std::tuple<int, time_t, int>; // task, start_time, duration using wait_info = std::tuple<int, int>; // source, target: source wainting for target to end std::queue<clock_info> clocks; // timer to wake up tasks std::queue<wait_info> waits; const int id_main = 0; const int id_reactor = 1; const int id_computation = 2; void add_clock(int task, int duration) { time_t start; time(&start); clocks.push(std::make_tuple(task, start, duration)); } void wait_for(int source, int target) { waits.push(std::make_tuple(source, target)); } void end(int task) { end_tasks.push_back(task); } ctx::continuation reactor(ctx::continuation && main_continuation) { ctx::continuation task; std::cout << "start reactor" << std::endl; tasks.push_back(std::move(main_continuation)); // add main continuation to list of tasks tasks_to_run.push(id_main); unsigned int k; time_t end_time; for (;;) { if (tasks_to_run.size()) { int id_task = tasks_to_run.front(); tasks_to_run.pop(); tasks[id_task] = tasks[id_task].resume(); } time(&end_time); for (k = 0; k < clocks.size(); k++) { clock_info clock = clocks.front(); int elapsed = end_time - std::get<1>(clock); if (elapsed > std::get<2>(clock)) { tasks_to_run.push(std::get<0>(clock)); } else clocks.push(clock); clocks.pop(); } for (k = 0; k < waits.size(); k++) { wait_info wait = waits.front(); if (std::find(end_tasks.begin(), end_tasks.end(), std::get<1>(wait)) != end_tasks.end()) { tasks_to_run.push(std::get<0>(wait)); } else waits.push(wait); waits.pop(); } } return std::move(main_continuation); } struct int_future { std::function<int()> func; int future_result; int_future(std::function<int()> f) :func(f) {} auto make_task() { return [this](ctx::continuation && main_cont) { tasks[id_reactor] = main_cont.resume(); future_result = this->func(); end(id_computation); tasks[id_reactor] = tasks[id_reactor].resume(); return std::move(main_cont); }; } int get() { wait_for(id_main, id_computation); tasks[id_reactor] = tasks[id_reactor].resume(); return future_result; } }; int call_server() { std::cout << "waiting for server results" << std::endl; add_clock(id_computation, 5); tasks[id_reactor] = tasks[id_reactor].resume(); result = 5; std::cout << "server returned result " << result << std::endl; return result; } int calculate() { return 1 + call_server(); } int main() { ctx::continuation task; tasks.push_back(ctx::callcc(reactor)); std::cout << "launch computation task" << std::endl; int_future fut(calculate); tasks.push_back(ctx::callcc(fut.make_task())); tasks_to_run.push(id_computation); tasks_to_run.push(id_main); tasks[id_reactor] = tasks[id_reactor].resume(); std::cout << "main task running" << std::endl; for (int j = 0; j < 10; ++j) { std::cout << a << " "; } std::cout << std::endl; std::cout << "wait for future" << std::endl; std::cout << "future result:" << fut.get() << std::endl; }

4 6

[docs] Building docs for release?
by John Maddock 15 Dec '18

15 Dec '18

Is there now a way for quickbook docs that aren't integrated under /doc/ to be built automatically for each release? And if so, what's the magic incantation to test this? Many thanks! John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

Windows quarantines boost_1_68_0.7z
by Miguel Ojeda 15 Dec '18

15 Dec '18

Quick note: it seems that Windows currently quarantines boost_1_68_0.7z. Could someone from Boost please contact Microsoft to whitelist it? Thanks, Miguel

5 11

C++Now (BoostCon) 2019 Call for Submissions
by Jon Kalb 14 Dec '18

14 Dec '18

The C++Now (formerly BoostCon) 2019 Call for Submissions is now open. http://cppnow.org/announcements/2018/12/2019-call-for-submissions/ C++Now will be held in Aspen, Colorado on May 5th - 10th. Colorado has become trendy for C++ conferences, but BoostCon was here first. If you are interested in Boost Libraries and have never attended C++Now, you owe it to yourself to have the BoostCon experience. The best way to get your company to send you is to have an accepted submission. The deadline is early in the new year, so don’t delay. Jon Kalb Conference Chair C++Now

1 0

Let's discuss dropping support for msvc <= 9.0 (2008), gcc < 4.6, clang < 3.4
by James E. King III 13 Dec '18

13 Dec '18

During the Boost 1.69.0 release there was a regression on Visual Studio 2005 (msvc-8.0). Microsoft ended support for msvc-8.0 on December 4, 2016. I was going to argue we let it happen, but it wasn't the right time to discuss that sort of change. Boost has a very large compatibility matrix which increases the effort required, and sometimes limits solutions development, to get out a quality release. The boost project as a whole agreed in summer 2018 that if repository maintainers wanted to drop C++03 support per repository to make substantial improvements or simplifications, or to ease maintenance then they are able to do so. *Folks who need support for older language levels and older compilers can always download an older version of Boost.* The compilers I mentioned in the subject have trouble with C++11 and are no longer maintained. msvc-8.0 (Visual Studio 2005) ended support Dec 10 2016 msvc-9.0 (Visual Studio 2018) ended support April 10 2018 The last release of gcc 4.6 was April 12, 2013 The last release of gcc 4.5 was July 02, 2012 The last release of gcc 4.4 was March 13, 2012 The compilers by default in Ubuntu Trusty 14.04.5 LTS, supported through April 2019, is gcc-4.8, currently at gcc-4.8.2, and clang 3.4 (however clang-3.8 is available). My argument is that this is a huge project, and maintaining backwards compatibility is not always efficiently possible. We spend build matrix resources testing and analyzing those tests. We find and develop fixes and workarounds. In some cases we hobble potential solutions to cater to decade-old compilers. Given the summer 2018 discussions about language level, and the aging vendor support matrix, I'd like us to consider dropping support for msvc <= 9.0 (2008), gcc < 4.6, clang < 3.4. What does this mean exactly? 1. We no longer test these compilers in the post-commit build matrix. 2. We no longer test these compilers in continuous integration. 3. We no longer develop fixes for issues that affect these compilers. 4. We are allowed, over time, to remove workarounds for these compilers. 5. We no longer block releases due to incompatibility with these compilers. 6. We remove these compilers from the documented environments in the release notes. 7. We direct anyone looking for support of these compilers to download a previous release of Boost that given them that support. 8. We do not update older Boost releases to fix issues with older compiler support. What would we remove from the release notes as a result? primary: linux: clang: c++03: 3.0 c++0x: 3.0 c++11: 3.0, 3.1, 3.2, 3.3 gcc: c++03: 4.4.7, 4.5.3 c++0x: 4.4.7 windows: gcc: c++03: 3.4.5, 4.1.2, 4.2.4, 4.3.3, 4.4.0, 4.5.4 msvc: - msvc-7.0 (Visual C++ 7.1) - msvc-8.0 (Visual Studio 2005) - msvc-9.0 (Visual Studio 2008) additional: linux: clang: c++03: 3.0, 3.8.1, 3.9.1, 4.0.1 c++0x: 3.0 c++11: 3.0, 3.1, 3.2, 3.3 gcc: c++03: 4.4.7, 4.5.3 c++0x: 4.4.7 windows: gcc: c++03: 3.4.5, 4.1.2, 4.2.4, 4.3.3, 4.4.0, 4.5.4 msvc: - msvc-7.0 (Visual C++ 7.1) - msvc-8.0 (Visual Studio 2005) - msvc-9.0 (Visual Studio 2008) The release notes section on compiler compatibility should probably be updated to match the current state of the post-commit matrix and duplicates in the "additional" section that are present in the "primary" section should be removed, or simply merge them. Why do we have a distinction here? Thanks for your consideration, Jim

12 16

Is disabling boost log auto flush the only way to control the log flush? Or can you change log auto flush rate?
by hh h 13 Dec '18

13 Dec '18

Hi, I use boost log in an embedded system where flushing log message to flash storage need be controlled. I could not find how to change log auto flush rate, is it the only way to disable auto flush boost::log::keywords::auto_flush = false? I think there must be a way to change a desired log flush rate value without disabling auto flush, appreciate any tips. Thank you. JHH

2 2

[coroutine] Boost.Coroutine 1.0 Deprecation Warning
by Vinnie Falco 13 Dec '18

13 Dec '18

Can we please turn off this deprecation warning for now? At least when Boost.Coroutine is being included to work with Asio? I get neverending complaints from users about this warning in Beast: <https://travis-ci.org/vinniefalco/beast/jobs/466272022#L1091> I am of course defining BOOST_COROUTINES_NO_DEPRECATION_WARNING: <https://github.com/boostorg/beast/blob/010fb4b08c05ce82cf4a87d9985c5b4998d9…> But this warning happens when building the coroutine library not when compiling Beast's tests and examples. Regards

3 2

[release] 1.70.0 open for merging
by Marshall Clow 12 Dec '18

12 Dec '18

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: https://github.com/boostorg/boost/wiki/Release-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

2 1

GSOC-19 Ideas
by Arihant Samar 12 Dec '18

12 Dec '18

Dear Boosters, I am new to the community. I wanted to ask if there will be any new suggested GSOC ideas for 2019. I went through the suggested proposals of 2018 but projects have already been done on most of them so It will be helpful if you could give some starting points. Sent from Mail for Windows 10 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 2

[release] Boost 1.69.0
by Marshall Clow 12 Dec '18

12 Dec '18

Release 1.69.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see < http://www.boost.org/users/news/version_1.69.0> You can also download directly from: < https://dl.bintray.com/boostorg/release/1.69.0/> SHA-256 sums: af05616f71006f97833e130aad886c96136457511ace4b5496d6566e69cbe0ca boost_1_69_0.7z 8f32d4617390d1c2d16f26a27ab60d97807b35440d45891fa340fc2648b04406 boost_1_69_0.tar.bz2 9a2c2819310839ea373f42d69e733c339b4e9a19deab6bfec448281554aa4dbb boost_1_69_0.tar.gz d074bcbcc0501c4917b965fc890e303ee70d8b01ff5712bae4a6c54f2b6b4e52 boost_1_69_0.zip To install this release on your system, see < http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Vladimir Prus, Marshall Clow, Daniel James, Micheal Caisse

2 3

[release] 1.69.0 closed for release
by Marshall Clow 12 Dec '18

12 Dec '18

The master branch is now closed for all changes except by permission. The commit-bot isn't running on master, so the super project will need to be manually updated for any changes. If all goes well, the release candidate should be out later today. Thanks, -- The Boost Release Team

4 7

The Master branch is still closed; it will be opened tomorrow
by Marshall Clow 12 Dec '18

12 Dec '18

Thanks for your patience -- The boost release managers

1 0

Fwd: [run-clang-tidy] new replacement overlaps with an existing replacement
by Mateusz Loskot 11 Dec '18

11 Dec '18

(I'm forwarding here my clang-tidy problem I posted to cfe-user mailing list, since it touches Boost library, a highly templated library, and I'm hoping we have experienced clang-tidy users among Boost developers. Considering it a part of Boost library development, I hope it is not off-topic here.) ---------- Forwarded message --------- From: Mateusz Loskot <mateusz(a)loskot.net> Date: Mon, 10 Dec 2018 at 22:14 Subject: [run-clang-tidy] new replacement overlaps with an existing replacement To: <cfe-users(a)lists.llvm.org> Hi, I'm running clang-tidy 7.0 (also tried 5.0) to modernise some aspects of Boost.GIL (https://github.com/boostorg/gil) source code. I've noticed, clang-tidy 7.0 (also 5.0) does not apply fixes for some of modernize-use-* checks, especially modernize-use-using. I run it this way: ``` cd ${BOOST_ROOT}/libs/gil cmake -S . -B _build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON .. run-clang-tidy.py -p=_build -header-filter='boost\/gil\/.*' -checks='-*,modernize-use-using' -fix ``` Then, I see huge number of "The new replacement overlaps with an existing replacement." diagnostics. Below, I copied an extract that hopefully is useful to figure out what is happening and going wrong. Basically, there are two class templates and a bunch of tag types: 1. file_stream_device https://github.com/boostorg/gil/blob/e0288ece9ec50534e7d02166863d6799a5932e… 2. get_write_device with partial specialisations, `enable_if`-ed https://github.com/boostorg/gil/blob/e0288ece9ec50534e7d02166863d6799a5932e… The file_stream_device is specialised for a tag and final get_write_device specialisation is matched. And, clang-tidy tries to substitute this alias in get_write_device typedef detail::file_stream_device< FormatTag > type; not with using type = detail::file_stream_device< FormatTag > ; but with `using type` for each FormatTag-based specialisation ``` New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<bmp_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<bmp_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<jpeg_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<png_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<png_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<png_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<pnm_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<targa_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<targa_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<tiff_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<tiff_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. ``` Why clang-tidy tries to re-fix the typedef with new replacement instead of keeping the existing one, the generic one? i.e. using type = detail::file_stream_device<FormatTag> I've tried to prepare a minimal example, but I couldn't reproduce this issue. I observed, that if I manually prepare compile_database.json with single .cpp file that just `#include <boost/gil/io/device.hpp>`, that is the header with definition of the base templates and no definitions with higher level specialisations for format tags are included, then clang-tidy applies the expected fixes without any warnings. Could anyone share any insights about this issue? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

How to install boost core
by Nipun Ramani 11 Dec '18

11 Dec '18

I am very new to boost and I have been wanting to build the library from scratch. I am using CMake with VS2017. I successfully created the project files of boost-core using CMake however I am unable to locate .lib file or .dll file after I run the build in VS2017.

2 1

[Website] Revised $Date$
by Olaf van der Spek 11 Dec '18

11 Dec '18

Hi, I don't think this is what it's supposed to be. > Revised $Date$ https://www.boost.org/development/index.html -- Olaf

1 1

Reminder: 1.69 closes for major changes Wednesday
by Marshall Clow 10 Dec '18

10 Dec '18

Upcoming dates: * 31-Oct: Boost 1.69.0 closed for major code changes * 7-Nov: Boost 1.69.0 closed for beta * 14-Nov: Boost 1.69.0 beta 1 * 5-Dec: Boost 1.69.0 closed for release * 12-Dec: Boost 1.69.0 release -- The Boost Release Team

4 3

Will the boost::asio::streambuf keep in sequency order when ostream write to boost::asio::streambuf multiple time?
by hh h 10 Dec '18

10 Dec '18

Hi, Are there any problems in following statements? The receiver works a few minutes, then got wrong number in header field. std::shared_ptr<boost::asio::streambuf> buffer = std::make_shared<boost::asio::streambuf>(); std::ostream os(buffer.get()); os.write((char *) &sendHeader, sizeof(sendHeader)); os.write((char *) sb.data(), sb.size()); boost::asio::async_write(socket_, *buffer.get(), .....); Thank you. - JHH

2 1

Is the async_read more reliable than async_read_some?
by hh h 09 Dec '18

09 Dec '18

Hi, I have been using asio::async_read with protobuf for some time, it is relative easy to use protobuf function SerializeToOstream to attach a packet header and send the packet header along with to protobuf message, with fixed packet header size and message size in the header, I was able to use async_read. But I have to change to use msgpack which I could not find a way like protobuf to attach a packet header to msgpack message. The only way I could do is to use async_read_some, but I am very concerning the remark in the async_read_some document. Appreciate your comments. "The read operation may not read all of the requested number of bytes. Consider using the async_read function if you need to ensure that the requested amount of data is read before the asynchronous operation completes." Thank you. - JH

3 9

Re: [boost] Can we skip the __boost_check_library__.test ?
by Rene Rivera 07 Dec '18

07 Dec '18

Rerouting to appropriate lists.. On Sun, Dec 2, 2018 at 6:00 PM Kuhl, Brian via Boost-build < boost-build(a)lists.boost.org> wrote: > Hi Boost builders, > > We currently running the Boost test suite using ./b2 in the status > directory. > > We run nightly on several simulators and real boards using ARM, PowerPC, > Intel processors compiling Boost 1.68 with clang and GCC > > Our test results are being peppered with the occasional failure of > __boost_check_library__ > > I’m pretty sure we don’t care about the results of this test in the > context cross-compiling VxWorks? > Probably not. > What exactly is it testing for? > It checks various requirements and guidelines of the library structure. > And assuming it isn’t relevant, how do we “turn it off”? > Add the "--no-check-libs" per < https://github.com/boostorg/boost/blob/develop/status/Jamfile.v2#L18> (I believe running b2 --help in that dir would have shown you that info also). > The library Jam files don’t have an explicit reference to this that I can > find? > It's added here < https://github.com/boostorg/boost/blob/develop/status/Jamfile.v2#L119>. And it runs this script < https://github.com/boostorg/boost/blob/master/status/boost_check_library.py >. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2 1

[release] Boost 1.69.0 Release Candidate 1
by Marshall Clow 07 Dec '18

07 Dec '18

The release candidates for the 1.68.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.69.0/source/> The SHA256 checksums are as follows: af05616f71006f97833e130aad886c96136457511ace4b5496d6566e69cbe0ca boost_1_69_0_rc1.7z 8f32d4617390d1c2d16f26a27ab60d97807b35440d45891fa340fc2648b04406 boost_1_69_0_rc1.tar.bz2 9a2c2819310839ea373f42d69e733c339b4e9a19deab6bfec448281554aa4dbb boost_1_69_0_rc1.tar.gz d074bcbcc0501c4917b965fc890e303ee70d8b01ff5712bae4a6c54f2b6b4e52 boost_1_69_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

1 1

Executable files in Boost git repostories
by Edward Diener 06 Dec '18

06 Dec '18

We have again run into the situation where files with a Linux executable permission have been committed to various Boost git repositories, with Jim King creating a PR and list of these files in Boost Admin. I have fixed these for the repositories for which I have write access, and created PRs for the other repositories. But this begs the question as to what Boost's stance should be about adding actual executable files to a Boost git repository ? As an example a Linux bash command file was added to a particular repository and I created a PR to remove the executable file permission from the file. But the maintainer of the repository feels this is wrong and the Linux bash file should retain the executable file permissions and that the file should be part of the repository. But of course I am more interested here about the general principal of the matter. Obviously operating system command/batch files are executable files, but should they be so in a repository. Finally should be not have some sort of git hook that somehow eliminates this recurring problem of files with executable permissions being periodically committed to a Boost git repository ? Most all of the files I "fixed" or created PRs for are clearly source files what can not be "executed" in any way. But this happening again is a real problem to have to clean up each time.

9 22

Reminder: Boost Master branch will close for release tomorrow (12/5)
by Marshall Clow 05 Dec '18

05 Dec '18

Calendar at https://www.boost.org/development -- Marshall

3 3

[histogram] should some_axis::size() return unsigned or int?
by Hans Dembinski 04 Dec '18

04 Dec '18

Dear community (especially the reviewers of boost.histogram), I am still working on finishing the library based on the excellent reviews I got in September. I cannot make up my mind about a specific detail of the library interface and would like to ask for your input. Every axis type is required to have a size() method, which returns the number of bins along that axis (without counting extra bins for under- and overflow). Should this method return `unsigned` or `int`? = The case for `unsigned` = The size of an axis is non-negative, so the return type should reflect this. All the STL containers return their size as an unsigned integer. Naturally, boost.histogram should be as consistent as possible with the STL, so you don't have think about exceptions from the general rule. Whether `size()` returns a signed or unsigned type matters even in times of `auto`, since compilers like to warn about comparisons between signed and unsigned integers. These warnings and the STL have slowly thought people to write indexed loops with unsigned integers, like so: ``` auto h = make_histogram(…); // 1D histogram for (unsigned i = 0; i < axis.size(); ++i) { auto x = h[i]; // do something with bin } ``` We don't want to break this painfully learned habit by letting `size()` return a signed integer, because it would generate a warning in this naive loop. = The case for `int` = The type of the bin index returned by an axis is `int`, because it can be negative. An axis is required to return -1 when the axis represents an ordered range and the value fall below the low edge of the first bin. So the index must be signed. The size of an axis is highest index + 1. It would be natural to use the same type for `size()` and for the returned index. Internally in the library, there are many less-than comparisons between the index and the size of the axis. If the type of the latter is unsigned, the size must be cast to `int` in all these comparisons to avoid compiler warnings, which is adding code clutter in the implementation. The library provides a range adaptor, called `indexed`, which allows one to iterate over the bins of a histogram with a special proxy, that can return the current bin index and the accumulated value for that bin. The following naive code to ignore under/overflow bins while iterating will generate a warning when `size()` returns `unsigned` ``` auto h = make_histogram(…); // 1D histogram // iterate over indexed bin range, ignore indices < 0 and indices > size (= underflow/overflow bins) for (auto x : indexed(h)) { if (x[0] < 0 || x[0] >= h.axis().size()) // without warning only when x[0] and h.axis().size() both return `int` continue; // do something with bin } ``` People are supposed to use the indexed range to iterate over the bins and not a combination of simple loops like in the first listing, because it scales nicely to multi-dimensional histograms. In multiple dimensions, it is also potentially more efficient. The `indexed` range adaptor automatically moves sequentially in memory, which this is not guaranteed if the index is created by looping manually over several indices, like so ``` for (unsigned i = 0; i < h.axis(0).size(); ++i) for (unsigned j = 0; j < h.axis(1).size(); ++j) { auto x = h.at(i, j); // this may jump around in memory, causing cache misses } ``` How the linear index is generated from the multi-dimensional index is an implementation detail (although the implementation should probably anticipate these naive loops…) So, if `indexed` is anyway the default recommended way of iterating over a histogram, then size() should return `int` to be compatible with the index type, which is also `int`, because it makes naive code work better. Sorry for the long email, I would really appreciate your input. Best regards, Hans

6 13

Re: [boost] [graph] Tree data structure
by Bjorn Reese 02 Dec '18

02 Dec '18

On 11/28/18 11:51 AM, Jeremy Murphy via Boost wrote: > long ago, back in 2002 and 2009, Kasper Peeters proposed adding his tree > data structure to Boost. There is also Rene's proposal, which sounds like a useful Boost library: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3700.html

2 1

Re: [boost] [histogram] should some_axis::size() return unsigned or int?
by Hans Dembinski 01 Dec '18

01 Dec '18

Dear Jim, > On 29. Nov 2018, at 13:31, Jim Pivarski <jpivarski(a)gmail.com> wrote: > > It seems to me that if other C++ containers use unsigned integers for size(), you should too, for minimal surprise. The issue you raise about the "which bin?" function returning -1 would be solved in a very-strongly typed language like Haskell as an optional<int>. I know that C++ has optional types now, but I don't know how widely they're used or if there's a significant performance penalty. If this wouldn't look too weird in a C++ program and wouldn't slow it down (or needlessly complicate the code), an optional type would describe your intent more fully than -1. there is boost::optional, which has the semantics of a pointer and can be used to represent a type that stores a value or not. ``` boost::optional o = some_fickle_function(); if (o) { // optional has a value? auto value = *o; // "dereference" to get the value } else { // handle case where value is missing } ``` This is not a good match here, because -1 here does not have the meaning of "value is missing", but it really is the logical index for the virtual bin that spans from -infinity to the lower edge of the first bin in the axis. Value arrow: -inf ——————— | ——————— | —————— | —————— |—————————> +inf bin -1 bin 0 bin 1 bin 2 bin 3 I think representing the underflow bin with -1 and the overflow bin with the value returned by size() is very intuitive and elegant. Best regards, Hans

5 10

C++ project suggestion for Google summer of code (summer, 2019 )
by Ahmed Hussein 30 Nov '18

30 Nov '18

Dear boost , My name is Ahmed Mohamed Ahmed. I ‘m an Egyptian second year electrical engineering student (this is my third year but in Egypt we count 0,1,2,3,4). This my first time ever getting involved in open source. Nevertheless, I am eager to contribute to the vast open source community . I would love to create a C++ library under your supervision and guiding in the next Google summer of code (summer,2019). The attached document is an overview of the library, it is not a proposal with a time line but it answers questions regarding: How is this library going to benefit the open source community? What facilities will be provided by that library? What kind of libraries can be built by fellow programmers using this library? How can this library be extended in the future, whether by me or others? Thank you for your time . Sincerely Advanced mathematics for engineering applications <https://docs.google.com/document/d/1hxKHm0vv5nvia-d_OcGd3SG07gCf2ZtMQvDn_LF…>

1 0

Current Guidance on Compiler Warnings?
by Brian Kuhl 29 Nov '18

29 Nov '18

I'd like to confirm the guidance on Warnings I find here https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines is still considered current? context ... At Wind River we are in the process of working with Boost 1.68 and VxWorks 7 (with Dinkum 7.00 with and Clang 6.0 for ARM and IA boards and GCC 8.1 for PowerPC ) with the hope of bundling Boost with our product. Many of our customers make certified systems ( Planes, Trains, Medical Equipment, Factory Automation, etc. ) and the trend in theses industries is to be pedantic about eliminating all compiler warnings. While we have not traditionally required zero warnings in open source code shipped with our product, there is pressure on us to move in that direction, and as result we will probably be contributing pull requests specifically to fix or suppress compiler warnings over the coming years. I'd like to establish clear guidelines for my team as to what is an appropriate "coding standard" for Boost in regards to compiler warnings. While it is simple to say, everything displayed by -Wall, in practice there are many edge cases, e.g. is an unused parameter acceptable in test code? So I'd like to get the maintainers guidance. Many thanks Brian Kuhl

23 103

[graph] Tree data structure
by Jeremy Murphy 28 Nov '18

28 Nov '18

Dear Boost community, long ago, back in 2002 and 2009, Kasper Peeters proposed adding his tree data structure to Boost. http://tree.phi-sci.com/ There was a lot of discussion but nothing eventuated (so far as I am aware). There are links to the historical discussions on his website. ...2018.... Recently, a Boost.Graph user suggested adding a tree class to it, and I was like, "No, no, a tree is just a graph that satisfies certain constraints: a tree class won't yield better performance." But I also happen to be re-reading for nth time, Element of Programming, which touches ever so briefly but intensely on binary trees, and I realized "Oh, hold on, there is a world of conceptual difference between an arbitrary tree, and a k-ary tree." That discussion is here: https://github.com/boostorg/graph/issues/123 It seems very awkward to even try to represent a k-ary tree in existing Boost.Graph data structures, let alone a mutable k-ary tree. So I made a proof-of-concept, a mutable k-ary tree data structure with specialized implementations of depth-first search and isomorphism. Unless I've made a terrible mistake (which is possible), the performance gains are huge, and the ease of use in an existing library is also huge. OK, so huge things aside, this is really early days, exploratory work. And I'm no Boost.Graph expert. I'm interested in what people think, particularly whether they think it is an idea worth pursuing. I do. But I basically need help from people smarter and more experienced. I have made a PR for the sake of discussion, not for actually merging: https://github.com/boostorg/graph/pull/139 Cheers. Jeremy

1 0

[threads] Launch deferred for async
by Stephan Menzel 28 Nov '18

28 Nov '18

Hello all, I am using boost::async() to create futures from tasks in order to wrap some behavior that may or may not be sync. This behavior is implemented behind an interface and can be small and fast operations or longer running and blocking things. All return a future as a result type, so I can hide the ugly truth. For the smaller stuff I'd like to use launch::deferred to avoid threading altogether and just execute the task when the user get()s the future. boost::future<bool> ret = boost::async(boost::launch::deferred, [this] () -> bool { // do some small cpu only impl return result; }); But when i get the result: const bool result = ret.get(); ...the application crashes. Debugging this I came to this in boost/thread/future.hpp:9373 } else if (underlying_cast<int>(policy) & int(launch::deferred)) { std::terminate(); //BOOST_THREAD_FUTURE<R> ret; //return ::boost::move(ret); // return boost::detail::make_future_deferred_shared_state<Rp>( // BF( // thread_detail::decay_copy(boost::forward<F>(f)) // ) // ); } else { To me this sounds like the application will always std::terminate() when launch::deferred is chosen. Why is that? When I use launch::any it seems to work but why is there a parameter that always yields unwanted results. What is the reason behind it? Can I get launch::deferred as it is described (not threading, just executing the task sync when get() is called) somehow? Platform is x64 Windows 10, MSVC14.1. Cheers, Stephan

2 4

[release] 1.69.0 post-beta merges
by Marshall Clow 26 Nov '18

26 Nov '18

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See < https://github.com/boostorg/boost/wiki/Release-Beta-Merge-Policy> The master branch will close for the 1.69.0 release on 5-December. The release calendar is at https://www.boost.org/development/index.html -- The Boost release team.

8 17

[release] 1.69.0 post-beta merges
by Oliver Kowalke 26 Nov '18

26 Nov '18

Hi, boost.context needs a post-beta merge in order to fix some issue on ELF asm. Do I get permission to merge to master? best, Oliver

2 1

Guidence on #pragma once
by Robert Ramey 25 Nov '18

25 Nov '18

In the safe numerics library my *.hpp files start with the following boiler plate: #ifndef BOOST_NUMERIC_AUTOMATIC_HPP #define BOOST_NUMERIC_AUTOMATIC_HPP // MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) # pragma once #endif ... I would like to replace all this in every file with just #pragma once according to https://en.wikipedia.org/wiki/Pragma_once#cite_note-9 this should be possible while supporting almost all which claim to be C++ 14 conformant. The exception noted is C++ for Cray. I realize that strictly speaking I shouldn't do this. But it would instantaneously remove some cruft from my code as long as the occasional error from repeating the same include guard text in multiple files. It might have some performance benefits and some other repercussions related to pre-compiled headers. Who knows what else. It would be interesting to know what others might have to say about this. Robert Ramey

10 10

[Boost][DoubleEnded] Status?
by degski 25 Nov '18

25 Nov '18

We had the review of this library proposal/addition quite a while back and ever since I've been [eagerly] waiting for its official entry into Boost. https://github.com/erenon/double_ended does not show any activity and there is nothing in the Boost.Container going on either. What is the status? degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*

4 6

Geometry path length breaking windows regression runs
by Tom Kent 23 Nov '18

23 Nov '18

There has been a change to the geometry library, sometime around Nov 14, that is causing the windows regression runners I manage to crash. The issue is that it is creating *very* long filesystem paths, even with the regression --abbreviate-paths option set. There are a bunch of files such as: D:\teeks99-08\run\results\boost\bin.v2\libs\geometry\test\self_contained_headers\self-contained-algorithms-detail-buffer-buffered_piece_collection~hpp.test\msvc-14.1\dbg\adrs-mdl-64\async-excpt-on\thrd-mlt\self-contained-algorithms-detail-buffer-buffered_piece_collection~hpp.obj.rsp That seem to be created alright, but when I try to cleanup the run afterwards, windows doesn't allow me to delete the files. Tom

5 4

Help - my disk is full! (of bin.v2 stuff)
by Paul A. Bristow 21 Nov '18

21 Nov '18

I note with surprise (and alarm) that my Boost-stuff disk partition is nearly full! Closer inspection reveals that I have a bin.v2 folder of over 50 GB. Obviously, I need to delete something. What are the implications of deleting things? What is the best option? Should I simply delete the whole folder bin.v2 (I have, in desperation, gone nuclear some time ago) or just bin/v2/libs or ? Expert advice welcome. Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

5 4

Rotating on-call review managers
by Zach Laine 19 Nov '18

19 Nov '18

Boost was originally created to incubate libraries that target eventual standardization. When new libraries are proposed, many of the Boost community members that participate in C++ Standard Committee (WG21) meetings ask "How many users does this have, and did you consider Boost first?" Often the answer is that they considered Boost but could not figure out what they were supposed to do to make that happen, or that they had difficulty finding a review manager. There are other things that can be done to make getting a library Boost-review-ready, but most of them require a bit of work up front. The review manager requirement is relatively easier to satisfy. This volunteer effort is to better facilitate Boost's value in the ISO C++ standardization process and so the reviewers would need to recognize intent to standardize the proposed libraries. Submissions that are supported with a paper in a mailing or a draft will make it easier to source a review manager from this queue, but authors without either are encouraged to get in contact with reviewers on this list to find out what that entails. This is the list of volunteers: Zach Laine Micheal Caisse Matt Calabrese Louis Dionne Vinnie Falco Glen Fernandes Jeff Garland David Sankel The list will rotate; the first person on the list will be "on-call". If you'd like to help, let me know and I'll add your name to the list. Also, I've made a PR that adds this list and a note like the description above to https://www.boost.org/development/submissions.html (#6 Seek a Review Manager): https://github.com/boostorg/website/pull/387 Zach

2 2

[release] Boost 1.69.0 Beta 1 Release Candidate 1
by Marshall Clow 19 Nov '18

19 Nov '18

The release candidates for the first 1.69.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.69.0.beta.1.rc1/source/> The release notes are not yet available. The updated documentation is not yet available. [ They will be available in a day or two. ] The SHA256 checksums are as follows: db6b346389714647490d6503db881e4178dd8cd498f850999bebf72cacd4c4ed boost_1_69_0_b1_rc1.7z d128c82351becbd37a02b9b4818994d3f66ff8bdbc0a18838206f4c070db97af boost_1_69_0_b1_rc1.tar.bz2 4df6262db53cfd0d0f934cb126f7e48e94872fe4441cbac6bf72a43bfb136a45 boost_1_69_0_b1_rc1.tar.gz e2908e33cc15f92cda06ddde6a3da43b18967a83105355571fc3cf6e75820c7f boost_1_69_0_b1_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

6 17

[release] Boost 1.69.0 Beta 1
by Marshall Clow 19 Nov '18

19 Nov '18

Boost release 1.69.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.69.0.beta1/source/> The SHA256 checksums are as follows: ee0ecd7d31f58474c1e0210089c9e66bd878d4d1e7436ac511e359aa4a9d3e86 ./boost_1_69_0_b1.7z 3e25c46f2171799caabbeb419ba7859fffb62208f3a1c80798713377ab07af0e ./boost_1_69_0_b1.tar.bz2 71f4b57175058af1b8c320971cf29226e5a652931a679f7e1c086655147ecafb ./boost_1_69_0_b1.tar.gz ec9ef7d2c9f0d41f560769e67bc7ff207cc999243a7dd6c3f6bcfbdbf0827a7b ./boost_1_69_0_b1.zip For details of what's in the release, see < https://www.boost.org/users/history/version_1_69_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

1 0

`b2 toolset=clang-win` now works on Appveyor
by Peter Dimov 18 Nov '18

18 Nov '18

With the current develop branch (since Boost.Build hasn't been merged to master yet), b2 toolset=clang-win now works on Appveyor without additional configuration. You can see it in action at https://ci.appveyor.com/project/pdimov/assert/builds/20331077/job/0hux9a6ml…

4 16

[release] Boost 1.69.0 Beta 1 Release Candidate 2
by Marshall Clow 18 Nov '18

18 Nov '18

The release candidates for the second 1.69.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.69.0.beta1.rc2/source/> The release notes are not yet final. The SHA256 checksums are as follows: 77827b25121159a4e65cfbdf19713e2d589fce267fd6f08615a453d24753c9d3 ./boost_1_69_0_b1_rc2.7z ea05c6e01c856369afdab1f6c075e06fb0f965ab1c247f753ed5c951a9db4e71 ./boost_1_69_0_b1_rc2.tar.bz2 b393a73cf084be716c40ef346cfacb1c95e7b14637e8385eeeb50774dd0b99ed ./boost_1_69_0_b1_rc2.tar.gz 74c0c0a19a700fee2b4f434bb7df50840642e3c35924e85864b278bd519af062 ./boost_1_69_0_b1_rc2.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

9 29

Re: [boost] [bjam] [build] Documentation for 1.69
by Rene Rivera 17 Nov '18

17 Nov '18

On Fri, Nov 16, 2018 at 1:54 PM Edward Diener <eldiener(a)tropicsoft.com> wrote: > On 11/16/2018 2:40 PM, Rene Rivera wrote: > > On Fri, Nov 16, 2018 at 1:27 PM Edward Diener via Boost < > boost(a)lists.boost.org> wrote: > >> >> It is not really a website/webpage issue but a distribution issue. The >> distribution has an index.html, which gives the doc for the >> distribution, and the link in the doc for the Tool Boost.Build never >> actually exists. >> > > This index.html? <https://github.com/boostorg/boost/blob/master/index.html> > Or some other one? > > In our distribution the top-level index.html brings up the doc. In the doc > there is a link to tools/build/index.html but this html file never exists > in a Boost distribution. Check out any of the past distributions, such as > Boost 1.68, and you will see this. > This <https://github.com/boostorg/boost/pull/218> should fix it. But We'll have to wait until the master branch is open again before it makes it to the release. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

1 0

[release] Boost 1.69.0 Beta 1 Release Candidate 3
by Marshall Clow 17 Nov '18

17 Nov '18

[ Ok, I've rebuilt the RC - and it contains only the changes to function and MPL ] The release candidates for the third 1.69.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.69.0.beta1.rc3/source/> The release notes are not yet final. The SHA256 checksums are as follows: ee0ecd7d31f58474c1e0210089c9e66bd878d4d1e7436ac511e359aa4a9d3e86 ./boost_1_69_0_b1_rc3.7z 3e25c46f2171799caabbeb419ba7859fffb62208f3a1c80798713377ab07af0e ./boost_1_69_0_b1_rc3.tar.bz2 71f4b57175058af1b8c320971cf29226e5a652931a679f7e1c086655147ecafb ./boost_1_69_0_b1_rc3.tar.gz ec9ef7d2c9f0d41f560769e67bc7ff207cc999243a7dd6c3f6bcfbdbf0827a7b ./boost_1_69_0_b1_rc3.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

1 1

[spirit] Request to update the master branch with minor doc changes
by Nikita Kniazev 16 Nov '18

16 Nov '18

Do I have a chance to cherry-pick minor doc changes into the upcoming release? I forgot to update version numbers in docs https://github.com/boostorg/spirit/commit/b4f5833cc69f510d3842ba226d8878bb4…

2 1

[build] targeting different versions of libstdc++
by James E. King III 16 Nov '18

16 Nov '18

If I make a system with libstdc++6-dev, libstdc++7-dev, and libstdc++8-dev on it, is there a way to tell clang to use one over the other? By default it will use the latest one. I know that for linking one can use the clang flag "--gcc-toolchain=/usr/lib/gcc/x86_64-linux-gnu/7" to get the link to point at it, but I'm not sure if this also handles the header paths or not. If this option works for both header inclusion and for linking, would I need to specify it as <cxxflags> and also as <linkflags>? Thanks, Jim

2 1

[bjam] [build] Documentation for 1.69
by Cromwell Enage 16 Nov '18

16 Nov '18

Hi, everyone! Will the documentation for Boost.BJam and Boost.Build be included in the release of Boost 1.69? Cromwell D. Enage

5 7

Announcing LEAF, a new error handling library suitable for low latency applications
by Emil Dotchevski 15 Nov '18

15 Nov '18

LEAF (Low-latency Error Augmentation Framework) is a new error handling library which could possibly become the successor of Boost Exception, though LEAF can be used without exceptions too. Official documentation: https://zajo.github.io/leaf/ Features: - No dynamic memory allocations. - Associate objects of arbitrary types with any failure -- when it is initially reported or at a later time. - Compatible with std::error_code, errno and any other error handling API. - Use with or without exception handling. - Support for multi-thread programming. Emil

4 9

Re: [boost] [Boost-users] [release] Boost 1.69.0 Beta 1 Release Candidate 1
by Marshall Clow 14 Nov '18

14 Nov '18

On Mon, Nov 12, 2018 at 4:30 PM Tom Kent via Boost-users < boost-users(a)lists.boost.org> wrote: > > On Mon, Nov 12, 2018 at 9:36 AM Marshall Clow via Boost-users < > boost-users(a)lists.boost.org> wrote: > >> The release candidates for the first 1.69.0 beta release are now >> available at: >> >> <https://dl.bintray.com/boostorg/beta/1.69.0.beta.1.rc1/source/> >> > As always, the release managers would appreciate it if you download >> the candidate of your choice and give building it a try. Please report >> both success and failure, and anything else that is noteworthy. >> > > toolset arch compile Link Execute > msvc-8.0 32 FAIL X X > msvc-8.0 64 FAIL X X > msvc-9.0 32 X X X > msvc-9.0 64 X X X > msvc-10.0 32 X X X > msvc-10.0 64 X X X > msvc-11.0 32 X X X > msvc-11.0 64 X X X > msvc-12.0 32 X X X > msvc-12.0 64 X X X > msvc-14.0 32 FAIL X X > msvc-14.0 64 FAIL X X > msvc-14.1 32 X X X > msvc-14.1 64 X X X > > Compile means that the b2 command completed without errors > Link means that visual studio was able to link a sample executable to a > library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib) > generated > Execute means that the linked program executed without errors. > > Full build logs can be found here: > https://gist.github.com/teeks99/526cf2598d1697557e45e590ce9517be > > Lots of errors with msvc-8.0: > > compile-c-c++ > bin.v2\libs\log\build\msvc-8.0\release\link-static\threadapi-win32\threading-multi\trivial.obj > trivial.cpp > .\boost/parameter/aux_/arg_list.hpp(227) : error C2064: term does not > evaluate to a function taking 1 arguments > .\boost/parameter/aux_/arg_list.hpp(390) : see reference to class > template instantiation 'boost::parameter::aux::arg_list<TaggedArg,Next>' > being compiled > > If there is an easy way to fix arg_list.hpp that would be nice, but if > this is the time to stop build 8.0, that's fine too. > > Also numerous errors for many (all dlls?) of the libraries with msvc-14.0. > They all look something like this: > > > msvc.link.dll > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll > Creating library > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.lib > and object > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.exp > msvc.link.dll > bin.v2\libs\system\build\msvc-14.0\release\threading-multi\boost_system-vc140-mt-x32-1_69.dll > Creating library > bin.v2\libs\system\build\msvc-14.0\release\threading-multi\boost_system-vc140-mt-x32-1_69.lib > and object > bin.v2\libs\system\build\msvc-14.0\release\threading-multi\boost_system-vc140-mt-x32-1_69.exp > msvc.link.dll > bin.v2\libs\container\build\msvc-14.0\release\threading-multi\boost_container-vc140-mt-x32-1_69.dll > Creating library > bin.v2\libs\container\build\msvc-14.0\release\threading-multi\boost_container-vc140-mt-x32-1_69.lib > and object > bin.v2\libs\container\build\msvc-14.0\release\threading-multi\boost_container-vc140-mt-x32-1_69.exp > msvc.manifest.dll > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll > 'mt' is not recognized as an internal or external command, > operable program or batch file. > > if exist > "bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll.manifest" > ( > call "bin.v2\standalone\msvc\msvc-14.0\msvc-setup.bat" x86 >nul > mt -nologo -manifest > "bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll.manifest" > "-outputresource:bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll;2" > ) > > ...failed msvc.manifest.dll > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.lib... > ...removing > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll > ...removing > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.lib > > I'm on the fence if we should continue supporting 8.0, so if that doesn't > get fixed then no big deal. However the issue with (the build tool?) for > 14.0 seems like a showstopper for this RC. > > Do we have any idea why MSVC 14 is failing? -- Marshall (who has been distracted by WG21 stuff)

4 4

What part of "The master branch is closed except by explicit permission" is confusing?
by Marshall Clow 14 Nov '18

14 Nov '18

That means "DO NOT COMMIT TO THE MASTER BRANCH" FULL STOP. I just turned on the auto-updating for the release, expecting two changes: * one from MPL * one from Function. Instead, I got updated from: * Update mpl from master * Update function from master * Update atomic from master * Update log from master * Update convert from master * Update iostreams from master You're making the release process harder. -- Marshall

3 2

Re: [boost] [Boost-users] [release] Boost 1.69.0 Beta 1 Release Candidate 1
by Marshall Clow 14 Nov '18

14 Nov '18

On Wed, Nov 14, 2018 at 9:02 AM Edward Diener via Boost-users < boost-users(a)lists.boost.org> wrote: > On 11/14/2018 11:06 AM, Marshall Clow via Boost-users wrote: > > On Mon, Nov 12, 2018 at 4:30 PM Tom Kent via Boost-users > > <boost-users(a)lists.boost.org <mailto:boost-users@lists.boost.org>> > wrote: > > > > > > On Mon, Nov 12, 2018 at 9:36 AM Marshall Clow via Boost-users > > <boost-users(a)lists.boost.org <mailto:boost-users@lists.boost.org>> > > wrote: > > > > The release candidates for the first 1.69.0 beta release are now > > available at: > > > > <https://dl.bintray.com/boostorg/beta/1.69.0.beta.1.rc1/source/> > > > > As always, the release managers would appreciate it if you > download > > the candidate of your choice and give building it a try. Please > > report > > both success and failure, and anything else that is noteworthy. > > > > > > toolset arch compile Link Execute > > msvc-8.0 32 FAIL X X > > msvc-8.0 64 FAIL X X > > msvc-9.0 32 X X X > > msvc-9.0 64 X X X > > msvc-10.0 32 X X X > > msvc-10.0 64 X X X > > msvc-11.0 32 X X X > > msvc-11.0 64 X X X > > msvc-12.0 32 X X X > > msvc-12.0 64 X X X > > msvc-14.0 32 FAIL X X > > msvc-14.0 64 FAIL X X > > msvc-14.1 32 X X X > > msvc-14.1 64 X X X > > > > Compile means that the b2 command completed without errors > > Link means that visual studio was able to link a sample executable > > to a library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib) > > generated > > Execute means that the linked program executed without errors. > > > > Full build logs can be found here: > > https://gist.github.com/teeks99/526cf2598d1697557e45e590ce9517be > > > > Lots of errors with msvc-8.0: > > > > compile-c-c++ > > > bin.v2\libs\log\build\msvc-8.0\release\link-static\threadapi-win32\threading-multi\trivial.obj > > trivial.cpp > > .\boost/parameter/aux_/arg_list.hpp(227) : error C2064: term does > > not evaluate to a function taking 1 arguments > > .\boost/parameter/aux_/arg_list.hpp(390) : see reference to > > class template instantiation > > 'boost::parameter::aux::arg_list<TaggedArg,Next>' being compiled > > > > If there is an easy way to fix arg_list.hpp that would be nice, > > but if this is the time to stop build 8.0, that's fine too. > > I have essentially backed out a fix on 'develop' for VC++8.0 which > intended to fix another problem with a multiple definitions linking > error, https://github.com/boostorg/mpl/pull/36. > > I would like to push this change to 'master'. It should fix your problem > above with VC++8.0. I will subsequently take another look at the > original fix and see if it can not be corrected. > If you're confident that this will fix the problem, then please do so. -- Marshall

1 0

Re: [boost] [Boost-users] [release] Boost 1.69.0 Beta 1 Release Candidate 1
by Marshall Clow 14 Nov '18

14 Nov '18

On Wed, Nov 14, 2018 at 8:35 AM Edward Diener via Boost-users < boost-users(a)lists.boost.org> wrote: > On 11/14/2018 11:06 AM, Marshall Clow via Boost-users wrote: > > On Mon, Nov 12, 2018 at 4:30 PM Tom Kent via Boost-users > > <boost-users(a)lists.boost.org <mailto:boost-users@lists.boost.org>> > wrote: > > > > toolset arch compile Link Execute > > msvc-8.0 32 FAIL X X > > msvc-8.0 64 FAIL X X > > msvc-9.0 32 X X X > > msvc-9.0 64 X X X > > msvc-10.0 32 X X X > > msvc-10.0 64 X X X > > msvc-11.0 32 X X X > > msvc-11.0 64 X X X > > msvc-12.0 32 X X X > > msvc-12.0 64 X X X > > msvc-14.0 32 FAIL X X > > msvc-14.0 64 FAIL X X > > msvc-14.1 32 X X X > > msvc-14.1 64 X X X > [snip] > Lots of errors with msvc-8.0: > [snip] > This is a result of a change in MPL for VC++8. I will back out this change. > Appreciated. Please test locally, and we'll watch the bots. (Looks like we have two MSVC-8 bots) -- Marshall

1 0

What is status of Boost.Sync?
by Mateusz Loskot 13 Nov '18

13 Nov '18

Hi, The library docs docs say it's been in Boost since 1.55. Boost master has no submodule for it. Boost develop has submodule for it If Sync was removed, why it is still in develop? If Sync was added, hence it is in develop, why the docs mention 1.55 and why it is not in master? What is the status of this thing? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Boost Test Matrix - no clang release builds?
by James E. King III 12 Nov '18

12 Nov '18

I was putting together some additional testing for a library and my CI jobs were failing in release mode. I was able to reproduce the issue locally. On examination of the boost test matrix however I was unable to see the same failures. When I dug into it a little bit more, it looks like the clang linux build jobs only build the default variant (debug), and therefore will not catch release-mode optimization issues when running the unit tests. Here's one of the job details: https://www.boost.org/development/tests/develop/teeks99-02-dc6-17-Docker-64… Given this matrix is the last line of defense before code is merged from develop to master, I'd suggest that the build jobs should all be targeting variant=release instead of variant=debug. The former directly impacts a release, and the latter does not. - Jim

4 3

[hash] Missing boost::hash_value for std::forward_list
by Alexander Zaitsev 11 Nov '18

11 Nov '18

Hello. Recently I found that boost::hash_value has no overload for std::forward_list. Who can tell me - why? Is there any reason and/or limitation? Thank you. -- Best regards, Alexander Zaitsev

1 0

[config] std::uncaught_exceptions
by Lorenzo Caminiti 11 Nov '18

11 Nov '18

Hello all, std::uncaught_exception (singular) is deprecated in C++17 and will be removed in C++20. std::std::uncaught_exceptions (plural) should be used instead. Will Boost.Config have a macro to detect if std::uncaught_exceptions is supported or not by the current compiler? (For example, Boost.Contract implementation uses std::uncaught_exception and it will need to use std::uncaught_exceptions on C++20 compilers instead.) Thanks. --Lorenzo

2 3

[release] 1.69.0 closed for Beta
by Marshall Clow 10 Nov '18

10 Nov '18

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_69_0.q… > You can preview the release notes at: <http://www.boost.org/users/history/in_progress.html> Thanks, -- The Boost Release Team

1 0

[release] many release notes pending
by Joaquin M López Muñoz 09 Nov '18

09 Nov '18

Just a heads up about the existence of many umerged lib-specific release notes at: https://github.com/boostorg/website/pulls I seem to remember this same issue happened in 1.68. Maybe some other protocol is needed for handling release notes. Best Joaquín M López Muñoz

6 10

Suggestions for TMP/function introspection problem?
by Hans Dembinski 09 Nov '18

09 Nov '18

Hi all, I am trying to figure out how to solve an introspection problem since a few days, and I am not making progress. I could use some help, it is for boost.histogram. Maybe what I want is not possible... Here is my problem. I have some classes A, B, ... which have some overloaded methods, let's call them `foo`. struct A { void foo(int, char); void foo(bool, int, char); }; struct B { void foo(double); void foo(bool, double); }; I need a way to detect how many arguments the shorter methods has. If the shorter method is foo(Ts...), the longer method is always (bool, Ts...). This is guaranteed. I do not know what Ts... is, it can be anything. I cannot use boost::callable_traits, because an overloaded member function cannot be fetched by name using t = boost::callable_traits::args_t<decltype(&A::foo)>; // fails, overload is ambiguous Can't I match the member function with a template of the form something(bool, Ts...) somehow? Any ideas? Best regards, Hans

2 4

Re: [boost] Boost.Build check to see if cxxflags flag is supported?
by Peter Dimov 09 Nov '18

09 Nov '18

> Note 4: > > This should probably be a feature, like <position-independent>on, which > toolsets translate to -fPIC as appropriate. ... which will fix the case where a shared library uses a static library, but -fPIC is not applied to the static library.

3 3

clang-win, (Thin)LTO this time
by degski 08 Nov '18

08 Nov '18

Starting new thread. Substantial progress has been made towards the goal of compiling Boost with Clang/LLVM (clang-cl.exe, targeting MSVC). The latest PR in this respect by Peter has achieved this. The next step is to be also able to use lld (lld-link in case of clang-cl.exe targeting MSVC) to generate the Boost-libs (static/dynamic). The main interest, IMO, is to be able to use LTO (Thin or Full), which is not possible without the use of LLD. A secondary benefit appears to be faster link times (info from the lld manual). In order to build static ThinLTO-enabled libs, it suffices to pass <compileflags>-flto=thin in the project jam file. The archiving, though, needs to be done with lld-link.exe, passing /lib as the first option (this way it will act as lib.exe, while being able to handle the llvm-byte-code [lib.exe finds the so generated .obj-files to be corrupt]). At consumption time of the libs, lld-link needs to be used for linking. Hacking clang-win.jam:156 to: toolset.flags clang-win.archive .LD $(cond) : "\"C:\\Program Files\\LLVM\\bin\\lld-link.exe\"" /lib ; achieves this goal. I would like to ask (probably Peter) to have a look into whether this can be achieved "the proper way", i.e. to programmatically set that particular line to the required value for this use-case. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*

4 13

Boost.Build check to see if cxxflags flag is supported?
by James E. King III 07 Nov '18

07 Nov '18

I'm looking for an example for how I could check to see if "-fPIC" is supported for the compiler as part of project requirements. In some recent PRs that include building a static library which then gets included in a shared library, code needs to be built with "-fPIC" on supported platforms/toolsets. There is some code in gcc.jam to do this if the overall link mode is shared (note: this code is not in clang.jam!), but in this case the overall link mode is static, and a Jamfile wraps the result in a shared library, so the directives in gcc.jam are not applied. So at the top level Jamfile, I want to add a project requirement that basically says, "if the compiler supports <cxxflags>-fPIC then use it". Thanks, Jim

3 2

Deadline for 1.69.0 beta extended
by Marshall Clow 07 Nov '18

07 Nov '18

The deadline for closing the master branch for the 1.69.0 beta has been extended until Friday, November 9th. The final release date has not been changed. -- Marshall (who is at a WG21 meeting all week)

1 0

[release][predef] Permission to merge to master..
by Rene Rivera 07 Nov '18

07 Nov '18

I have a change that adds some missing version information for Cygwin OS detection < https://github.com/boostorg/predef/commit/62a50d3892789076272b771f560a419b9…>. Can I merge that to master? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2 1

"peer reviewed" - Rights and responsibilities of maintainers
by Alexander Grund 07 Nov '18

07 Nov '18

I'm having trouble with a maintainer of a boost library over a PR and am seeking for clarification. Background (may be skipped): A bug was introduced into the library which I noticed in one of "my" (company) projects leading to a reproducible crash. However the scenario is not that common (although others have the same problem) so it wasn't noticed earlier. I analyzed the problem and created a minimum working example to reproduce this and then opened a PR with a fix. The maintainer did not comment on this for multiple months so given it IS complicated, I factored out additional PRs with tests I created to show the problem, so each PR is fairly small. In the result there were PRs with tests that failed on travis and the fix-PR which included the test-PRs and the fix and succeeded on travis (and all other CIs) and users reported success using this PR. Still no response from the maintainer on any PR. He then added an own test claiming to be enough, while I (as the author of the original tests) knew it wasn't as e.g. it didn't fail. (so what's it worth then?) Furthermore he added a commit changing unrelated stuff and ADDITIONALLY changing code I touched in the fix claiming that it would be the essence of my patch and fix the problems. Again I (as the author of the original patch) know that this is not true especially as the test-PRs still fail with his patch applied. So my point/problem is: Is the maintainer allowed to simply do changes as he wishes without any review at all? My expected procedure is: - Someone creates a PR - Maintainer (and optionally the community) reviews (and comments on) it - It eventually gets merged or rejected with comments why OR: - Someones else (including the maintainer) creates a contra-PR fixing the same problem - That author explains, how and why this fixes the same problem and why it is superior to the original PR - This gets reviewed and either PR gets merged Arguments were made, that this doesn't apply to accepted boost libraries as e.g. "it's [the maintainers] heads that got chopped off if something gets broken". I would challenge this by the simple example at hand: This boost library IS broken and it crashes MY application (and others). But I see no heads rolling. Furthermore: If the maintainer is allowed to patch and change as he wants without ANY review, how can Boost still be called "peer reviewed"? My trust in Boost stems from the extensive review a library has to undergo before it is included in Boost. If afterwards no review is happening or reviews are actively avoided (as in the current example), then the older a Boost library gets, the less trust I would have in it as more and more unreviewed changes get included. So again: What is the Boost course on reviews of existing libraries and the statement on the rights and responsibilities of maintainers? Thanks, Alexander Grund

15 52

[parameter] Go C++11 and above only, or keep C++03 support?
by Cromwell Enage 06 Nov '18

06 Nov '18

Hi, everyone. The end of section 3.2.1 of the current Boost.Parameter home page tutorial notes "that because of the forwarding problem, parameter::parameters::operator() can't accept non-const rvalues". I've submitted a PR to the develop branch on GitHub that would grant Boost.Parameter the ability to support perfect forwarding and eliminate this issue. However, the PR uses rvalue references (in parameter::keyword, parameter::parameters, and the code generation macros) and variadic templates (in parameter::parameters and the code generation macros). With the exception of BOOST_PARAMETER_TEMPLATE_KEYWORD, the PR would make Boost.Parameter a C++11 library. As a result--based on < http://pdimov.github.io/boostdep-report/develop/parameter.html#reverse-depe…>--the following Boost libraries known to use Boost.Parameter would also become C++11: Boost.Accumulators Boost.Convert Boost.Graph Boost.Heap Boost.Log Boost.MetaStateMachine or Boost.MSM Boost.Parameter_Python Boost.Signals2 I'd like to hear from everyone else, especially the maintainers and users of these libraries, if it's okay for Boost.Parameter to go C++11 and above only or if C++03 support is still necessary. Cromwell D. Enage

14 37

[testing] Lots of spurious test runners
by John Maddock 05 Nov '18

05 Nov '18

There are rather a lot of test runners that fail all tests due to setup errors: sandia-gcc-5.4.0-c++11 cc1plus: error: unrecognized command line option "-std=c++11" sandia-gcc-5.4.0-c++14 cc1plus: error: unrecognized command line option "-std=c++14" sandia-gcc-6.4.0-c++11 cc1plus: error: unrecognized command line option "-std=c++11" sandia-gcc-6.4.0-c++14 cc1plus: error: unrecognized command line option "-std=c++14" sandia-intel-16.0-c++11 /bin/sh: line 1: icpc: command not found sandia-intel-16.0-c++14 /bin/sh: line 1: icpc: command not found sandia-intel-16.0 /bin/sh: line 1: icpc: command not found sandia-intel-17.0-c++11 /bin/sh: line 1: icpc: command not found sandia-intel-17.0-c++14 /bin/sh: line 1: icpc: command not found sandia-intel-17.0 /bin/sh: line 1: icpc: command not found teeks99-02-dc3.1-11-Docker-64on64 /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/functional:2194:2: error: no type named 'type' in 'std::enable_if<false, void>' (and more errors from <functional> - the compiler appears to be unable to handle the std lib headers so I'm not sure what the point of testing it is?) igaztanaga-develop-gcc-3.4c++03 cc1plus.exe: error: unrecognized command line option "-fvisibility-inlines-hidden" cc1plus.exe: error: unrecognized command line option "-fvisibility=hidden" Best, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

4 3

interest in a flag library
by Masse Nicolas 05 Nov '18

05 Nov '18

Hi all, This is the first time I post on this mailing list :). I'm posting because i'd like to know if people would be interested in a library to treat enum types as flags. I find that's something which is lacking in the language since the introduction of strongly typed enums, and I've since written some code in order to do this. So far I've seen some discussion on this mailing list about that, but it doesn't seems that any library have been written yet. So do you think it is worth the effort of porting and documenting my code so that it can integrated into boost, or not? Regards, Masse Nicolas. PS: For those interested, the code consists of a flag class, and overloads operators like '|' or &. It can be used like this: enum struct option : uint { none = 0, first = 1, second = 2, third = 4, forth = 8 }; static constexpr flags<option> var1 = option::first; static constexpr flags<option> var2 = option::second | option::third; static constexpr auto var3 = var1 | var2; /* type will be resolved into flags<option> */ static constexpr auto var4 = option::first | option::second | option::third; /* works too */ int main() { std::cout << var1 << std::endl; std::cout << static_cast<uint>(var2) << std::endl; /* note that static_cast<int> won't compile since the underlying type is uint */ std::cout << (var3 & option::forth) << std::endl; std::cout << (var3 == var4) << std::endl; return 0; }

8 9

Boost.CI for Boost Repository Build Quality
by James E. King III 05 Nov '18

05 Nov '18

Continuous Integration is a modern cornerstone of delivering quality results in software engineering. When I started getting involved in boost as a maintainer (instead of a long-time consumer) it became a goal to get CI into as many repositories as possible. CI allows submitters to self-check their code changes without bothering the maintainer(s) of each repository. It eases the burden for maintainers as they can focus more on code review, and less on manual machinations to validate changes (by running code locally in their own environments). The wide coverage of builds in Boost.CI has helped identify a number of issues and improved the quality of those repositories. Performing these tests and analyses before code is merged catches issues earlier (but is not as comprehensive as the test matrix in terms of platform support due to limitations in the CI providers). Given that the Travis CI and AppVeyor builds for almost all the CMT repositories (and a few others) are using Boost.CI, it's proper place is under the "boostorg/" GitHub organization. Right now it's under my GitHub account, but I would like to move it to a more official location. https://github.com/jeking3/boost-ci Thanks, Jim

3 4

Draft copy - Call for Submissions - CMake for Boost
by Robert Ramey 05 Nov '18

05 Nov '18

The following is a draft of the document of I have planned to post on behalf of Boost on or around 1 November 2018 as the first step in our next attempt to accommodate CMake in Boost. Robert Ramey Call for Submissions - CMake for Boost ====================================== For some time, there has been interest on many users and developers of Boost Libraries to make Boost easier to use with CMake. Discussions in the past have not resulted in an implementation which has been widely accepted. Never the less, hope springs eternal, and we intend to attempt this once again. It seems that often there are difficulties before such projects even start in that there are wide discrepancies as to what should be the goals and expectations of Boost support of CMake. The aim of this document is to try to build a consensus on this question before encouraging CMake developers and experts to submit proposals for Boost support of CMake. Requirements and Scope ====================== Requirements ------------ Submissions will fulfill the applicable requirements of any boost submission. This will include: a) any necessary code. b) specifications/requirements for things like directory structure and contents. b) A useful document. Document should provide information, examples and templates so that a typical C++ and CMake user should be able to do any of the following in a short time - say 10 minutes. Document at a minimum should be viewable as html and/or PDF file. 1) A library user should be able to incorporate a Boost Library into the CMake script. 2) A library user should be able to determine which additional Boost Libraries he needs. 3) A library developer should find it simple to create the requisite CMake files for his library. Thus the documentation should contain explanation and perhaps other means such as examples and/or "templates" for required CMake files. c) test of CMake facilities supported by the CMake implementation. This will include code, test of any features, capabilities that the submission provides. Users expect that if they follow the instructions in the documentation, they will get the promised results. A manner of proving this must be provided. A likely response to this requirement would be a "test project" which can be used to demonstrate that the submission actually works. This will be useful in the future for maintenance of the CMake Boost implementation. It will permit the maintainer of the Boost.CMake facility to work on and test their fixes and improvements without disrupting other developers and users. d) a Boost License Facilities and features ----------------------- CMake as it stands has lots of capabilities. But it has a fair amount of complexity as well. Lots of things can be accomplished in multiple different ways - each with subtly different results and effects. CMake for Boost will likely consist of documentation, examples, CMake code, and other stuff to use CMake to permit new features and facilities for users and developers of Boost libraries. What follows is a list of facilities that Boost users and developers would like to acquire with CMake for Boost. Those marked with * should be considered hard requirements. That is, submissions which don't include this feature can't be considered. Other items are interesting and would be considered if included in a submission. *a) incorporating selected Boost Libraries into a user's application *b) incorporating selected Boost Libraries into a user's library c) building a boost library d) building a boost tool such as Boost.bcp, Boost.boostdep, etc. e) testing a boost library - if testing of Boost libraries is to be supported, the following features should be considered. Those marked * should be considered essential. *1) execution tests - must pass/ must fail *2) compile only tests - must pass/ must fail *3) link only tests - must pass/ must fail 4) should be available to both users and developers 5) should not depend upon tools other than C++. 6) test should have the option of posting the results to some public "dashboard" 7) option for recursive testing and/or building of libraries might be nice. That is if library A uses library B and I test library A, this would automatically test library B beforehand. *f) In CMake, dependent libraries are specified as part of the library CMakeLists.txt files. There several ways to do this and the subject is pretty confusing to get right. Any submission documentation has to explain to library developers how do this. g) Some have suggested a highly automated process including downloading/updating, finding other components on other machines, etc. This shouldn't be considered h) packaging - preparation of distributable, installable files for various operating systems. That is support for the CPack facility. i) There has been a lot interest and work in automatically determining dependencies It's a much deeper subject than most people realize. Solving this problem is not a requirement of the submission. However, submitters are free to address this if they desire. *j) support of library modularity. This would mean: *1) independence of things outside the library directory structure. To wit - no presumption about any "super project". *2) building out of tree *3) no need for installing libraries not used by the build target k) ... Submission Rules and Procedures ------------------------------- a) This document constitutes a "Request for Submissions". It will be announced on the boost announcements list, boost developer's list, slack/boost, isocpp website and twitter account, reddit at r/cpp. Submissions will be open to anyone. b) Submissions will be accepted at an email address to be specified. Received submissions will receive a "prescreening" to determine that they meet the requirements specified for such submissions at the top of this document. Those that don't will be returned to the author. c) The name of the author of a submission will not be included in the submission. Authors will be expected to take reasonable efforts to maintain his anonymity via a github repo without a real name assigned, anonymous, email address etc. We understand that the nature of the submission and debate during subsequent review of the proposals. Never the less we believe that anonymity can be mostly maintained. The the true identity of the author of the selected proposal will not be revealed until the selection is made. The motivation for this anonymity is to attract submitters who find the boost review process distressing, annoying and/or unpleasant. It should also address the concerns of those who beleive that by not being a "boost insider" they won't get fair consideration. Boost is first and foremost a meritocracy. We seek the very best in everything regardless of other considerations. d) Submissions will be closed on or about 1 February 2019. Boost formal review will commence shortly there after. Depending on the number of submissions received, the process may last as long as month. e) As per the boost formal review rules and customs, some time after the review period terminates, the review manager will announce the review results. This will likely contain some conditions regarding alterations required in the submissions implementations. I the author find these too onerous, and declines the opportunity to integrate his submission as an official part of boost, the review manager may select an alternate submission. It's also possible that the review manager may decide to accept none of the submissions. f) when the submission is integrated into boost and is shown fulfill the requirements stipulated by the review manager. The author will receive a "prize" of $5000 and a large but cheap medal on a ribbon hopefully to be awarded at the next C++Now (Boost Con). As this is written, this prize is subject to finding a funding source. It's understood that this stipend is in no way compensation, for all the work and aggravation of this task. But we hope that it will serve as a tangible token of our gratitude for solving one of Boosts most pressing and difficult problems. Useful Resources =============== “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1 https://github.com/purpleKarrot/Boost.CMake https://steveire.wordpress.com/2016/08/21/boost-dependencies-and-bcp/

10 28

Has anyone thought about adding a general case subset class?
by jrmarsha 04 Nov '18

04 Nov '18

I've got a lot working with my madlib version of graph, but I've been thinking over the elegant ways to add the subgraph feature in BGL. It occurred to me that this can be phrased as a more general problem as container subsets. And while we're at that, then we can add objects or operators for set operations like inner join, left join, and outer join. Can I get some thoughts?

1 0

Fwd: Errors in test matrix
by Stefan Seefeld 03 Nov '18

03 Nov '18

[I haven't received a reply on the boost-testing list, so I'm resending to the general list in the hopes that someone can help.] -------- Forwarded Message -------- Subject: Errors in test matrix Date: Wed, 31 Oct 2018 09:41:05 -0400 From: Stefan Seefeld <stefan(a)seefeld.name> To: Running Boost regression tests <boost-testing(a)lists.boost.org> Hello, [I'm not entirely sure this is the right place for the report. Please let me know if it isn't, and where to post instead.] On https://www.boost.org/development/tests/develop/developer/numeric-ublas.html, I'm looking at failures in the "Sandia" columns. Following one link takes me to https://www.boost.org/development/tests/develop/developer/output/Sandia-gcc…, which demonstrates a couple of issues: * What compiler version is this using ? The URL contains both "5.4.0" as well as "4.4.7". * The actual error reads "unrecognized command line option -std=c++11". Given that Boost.uBLAS itself doesn't specify this flag, I assume it's part of the test runner's configurations. However, it seems to be used with a compiler version that doesn't support it (though again, it isn't clear which compiler version we are actually talking about). Unfortunately there are quite a large number of columns with similarly generic errors, i.e. errors more likely to be caused by invalid set ups, rather than genuine errors in the library (libraries, as I'm seeing similar errors in other libraries). What can I do about this ? Ignore the errors ? It would be good if the metainfo that is displayed with the test runners included a point of contact (mail address ?) to report such errors. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

2 1

Re: [boost] [parameter] Go C++11 and above only, or keep C++03 support?
by Nikita Kniazev 03 Nov '18

03 Nov '18

The major problem is that Boost does not see its users; most of them do not read mail lists and changelogs, even documentation is read only during active development and by developers who actually touches boost namespace. To library maintainers they usually appear only when something is completely broken and we cannot blame anyone about it, but it makes nearly impossible to gather any statistics. The other point is that Boost is free and users may decide not to raise their voice because it can look like they try to dictate investment priorities of others spare time. If Boost really wants to survey C++03 users it can be most effectively done in the code by showing them a message with a conditional pragma #error “Boost wants to hear your voice. It is time to revise the minimal requirements. Please give us feedback about your preferences at <url> or mail list. To continue #define BOOST_I_ACKNOWLEDGE_EMERGING_CXX03_DEATH” in some libraries or globally in Boost.Config headers. It is not too late to make this for 1.69.

2 1

[release] 1.69.0 closed for major changes
by Marshall Clow 01 Nov '18

01 Nov '18

The master branch is now closed for new libraries and breaking changes, and will be closing for the beta in one week. Also, if you're ready, you can also add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_69_0.q… > After editing the release notes, you should get a form to create a pull request, remember to submit it, otherwise I won't see your change. Thanks, -- The Boost Release Team

1 0

clang-win, again
by Peter Dimov 31 Oct '18

31 Oct '18

Has anyone succeeded in getting clang-cl.exe working under b2? I've installed llvm-6.0.1, added it to PATH, put using clang-win : : : <compatibility>vc14 ; in my user-config, and what I get is: C:\boost-git\develop\libs\smart_ptr\test>b2 toolset=clang-win sp_interlocked_test warning: mismatched versions of Boost.Build engine and core warning: Boost.Build engine (b2) is 2015.07.00 warning: Boost.Build core (at C:/boost-git/develop/tools/build/src) is 2018.02-git C:/boost-git/develop/tools/build/src/tools\msvc.jam:1087: in set-setup-command *** argument error * rule virtual-target.from-file ( file : file-loc : project ) * called with: ( : /C:/boost-git/develop/libs/smart_ptr/test : object(project-t arget)@129 ) * missing argument file C:/boost-git/develop/tools/build/src/build\virtual-target.jam:970:see definition of rule 'virtual-target.from-file' being called C:/boost-git/develop/tools/build/src/tools\msvc.jam:652: in clang-win.compile.c+ + C:/boost-git/develop/tools/build/src/kernel\modules.jam:107: in modules.call-in C:/boost-git/develop/tools/build/src/util\indirect.jam:105: in indirect.call C:/boost-git/develop/tools/build/src/build\virtual-target.jam:902: in execute C:/boost-git/develop/tools/build/src/build\virtual-target.jam:821: in class@acti on.actualize C:/boost-git/develop/tools/build/src/build\virtual-target.jam:332: in actualize- action C:/boost-git/develop/tools/build/src/build\virtual-target.jam:518: in actualize- no-scanner C:/boost-git/develop/tools/build/src/build\virtual-target.jam:142: in class@virt ual-target.actualize C:/boost-git/develop/tools/build/src/build\configure.jam:258: in try-find-build C:/boost-git/develop/tools/build/src/build\configure.jam:396: in find-builds-raw C:/boost-git/develop/tools/build/src/build\configure.jam:455: in configure.find- builds C:/boost-git/develop\boostcpp.jam:734: in boostcpp.deduce-address-model C:/boost-git/develop/tools/build/src/kernel\modules.jam:107: in modules.call-in C:/boost-git/develop/tools/build/src/util\indirect.jam:105: in indirect.call C:/boost-git/develop/tools/build/src/build\property.jam:144: in property.evaluat e-conditionals-in-context C:/boost-git/develop/tools/build/src/build\targets.jam:1087: in evaluate-require ments C:/boost-git/develop/tools/build/src/build\targets.jam:1121: in common-propertie s2 C:/boost-git/develop/tools/build/src/build\targets.jam:1017: in targets.common-p roperties C:/boost-git/develop/tools/build/src/build\targets.jam:1313: in class@basic-targ et.generate C:/boost-git/develop/tools/build/src/build\targets.jam:812: in generate-really C:/boost-git/develop/tools/build/src/build\targets.jam:784: in class@main-target .generate C:/boost-git/develop/tools/build/src\build-system.jam:797: in load C:\boost-git\develop\tools\build\src/kernel\modules.jam:295: in import C:\boost-git\develop\tools\build\src/kernel/bootstrap.jam:139: in boost-build C:\boost-git\develop\boost-build.jam:17: in module scope

9 74

[property-tree] state of the library, fixes and extensions
by Goehring, Christian 31 Oct '18

31 Oct '18

Hi @all, the property-tree lib seems to be in some sort of dormant state judging from the repository activity. Is this library still actively maintained (for example, the xml-functionality would need some support for CData)? Do you know if there is any need for extensions (for example JSON-support) or did some other alternative succeed this library? Thanks in advance! Best, Christian

1 0

questions regarding visibility and b2
by Robert Ramey 30 Oct '18

30 Oct '18

I've got a few questions about the "visibility" changes for boost. My understanding is that "visibility" for gcc and clang are "sort of the same thing" as dll import and export are for windows. Now we've made "visibility" the "default". But this seems kind of weird. This has been made a b2 feature. In order to run tests, this feature is applied to the b2 command line. What's weird is that it's applied to the tests/executables and propogated down to libraries which are built. I actually don't know what "visibility" means in the context of building and executable. If I want to use visibility=global then on the library build, it needs to be applied to everything. It's very weird and doesn't seem in line with the windows solution. Heretofore, I've applied visibility to the library build "by hand" by adding the appropriate command line switches to the right places. I'm aware that this is not the b2 way. But the b2 way doesn't seem to make sense to me. On the bright side, changing default visibility didn't seem to have any effect on the serialization library other than on one test. Unfortunately, turning this confused a pending issue and made it even more contentious than it already is/was. FWIW - this is not so much the fault of b2 or anyone in particular. The use of DLLS/shared libraries is the triumph of development over design by vendors, each of whom do their own thing and have never been able to get it together. By now this has created enough technical debt that it will take years to straighten out if people actually start to address it, which no one seems interest in doing. Anyway, the b2 approach is pretty confusing and probably wrong. I'm also guessing that, as one would predict, a change like this is going to provoke subtle failures in lots of small corners which will take quite a while to discover. I'm not sure how to address this. Robert Ramey

4 5

[release] 1.69.0 deadline for new libraries approaching
by Marshall Clow 29 Oct '18

29 Oct '18

It's that time again! On Wednesday, the master branch will be closed for adding new libraries. Upcoming dates: * 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes * 31-Oct: Boost 1.69.0 closed for major code changes * 7-Nov: Boost 1.69.0 closed for beta * 14-Nov: Boost 1.69.0 beta 1 * 5-Dec: Boost 1.69.0 closed for release * 12-Dec: Boost 1.69.0 release -- The Boost Release Team

7 10

Is boost supported on z/os
by Naveen Sharma 28 Oct '18

28 Oct '18

Hello Does boost supported on z/os or may be subset of library. We are planning to replace our current library with boost. One of the platform we support is z/os and so I am researching if boost can be compiled and usable on the platform. I did searched on the internet but did not get much information. Before I dive into it, I thought to ask. Thanks Naveen

2 2

Re: [boost] [histogram] Objections against switch to C++14?
by Bjorn Reese 28 Oct '18

28 Oct '18

On 10/22/18 6:42 PM, Hans Dembinski wrote: > Do you object against raising the requirement from C++11 to C++14 for the implementation of boost.histogram? No objection from my side. However, you may consider making parts of the library available to C++11 users, because there are plenty of those out there.

1 0

Builds from boost/status fail early?
by James E. King III 27 Oct '18

27 Oct '18

Using develop from this morning (tried various combinations of these three options...): boost@d48d3305d4b4:/boost/status$ ../b2 toolset=clang variant=release cxxstd=03 ... /boost/tools/build/src/build/feature.jam:491: in validate-value-string from module feature error: "shared:" is not a known value of feature <link> error: legal values: "shared" "static" /boost/tools/build/src/build/feature.jam:365: in expand-subfeatures-aux from module feature /boost/tools/build/src/build/feature.jam:422: in expand-subfeatures from module feature /boost/tools/build/src/build/feature.jam:871: in feature.expand from module feature /boost/tools/build/src/build/targets.jam:1103: in evaluate-requirements from module targets /boost/tools/build/src/build/targets.jam:1121: in common-properties2 from module targets /boost/tools/build/src/build/targets.jam:1017: in targets.common-properties from module targets /boost/tools/build/src/build/targets.jam:1313: in class(a)basic-target.generate from module object(typed-target)@47912 /boost/tools/build/src/build/targets.jam:812: in generate-really from module object(main-target)@70272 /boost/tools/build/src/build/targets.jam:784: in class(a)main-target.generate from module object(main-target)@70272 /boost/tools/build/src/build/targets.jam:273: in class(a)project-target.generate from module object(project-target)@47307 /boost/tools/build/src/build/targets.jam:273: in class(a)project-target.generate from module object(project-target)@4568 /boost/tools/build/src/build-system.jam:797: in load from module build-system /boost/tools/build/src/kernel/modules.jam:295: in import from module modules /boost/tools/build/src/kernel/bootstrap.jam:139: in boost-build from module /boost/boost-build.jam:17: in module scope from module

3 12

[statechart] visibility change broke things
by James E. King III 27 Oct '18

27 Oct '18

Boost.StateChart wasn't building on a regular basis. It looks like the visibility changes broke it. I opened an issue for it. I also changed Travis CI to build it monthly.

1 0

[serialization] boost:array
by Yuval Lifshitz 27 Oct '18

27 Oct '18

Any idea on why was the serializer for boost:array removed?Can we re-introduce it? Yuval Lifshitz

1 0

Fwd: Syntax highlighting for Boost.Jam language in Visual Studio Code
by Mateusz Loskot 27 Oct '18

27 Oct '18

I've announced this on boost-build but I think folks here may find it useful as well. Mat ---------- Forwarded message --------- From: Mateusz Loskot <mateusz(a)loskot.net> Date: Fri, 26 Oct 2018, 23:18 Subject: Syntax highlighting for Boost.Jam language in Visual Studio Code To: <boost-build(a)lists.boost.org> Hi, (A pet project warning!) I've published an extension for VSCode with a brave attempt to color-hightlight syntax of Jam language: https://github.com/mloskot/vscode-boost-jam This is based on a very basic TextMate language grammar definitions, often naive, and, by no means, it is complete or bug-free coverage of the Jam. Even so, I think it quite helps to de-annoy or even enjoy process of writing Jam scrips :-) I'm no expert of writing TextMate language grammars - this is my first ever attempt - so chances are I may be incapable of fixing bugs or improving it with advanced features. Especially, that "the process of writing a TextMate language grammar remains poorly documented" - http://www.apeth.com/nonblog/stories/textmatebundle.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Mailman upgrade
by Brad Johnson 27 Oct '18

27 Oct '18

Happy Late October all. Just a quick notification that mailman upgraded from 2.1.26 -> 2.1.29 at 27-Oct-2018 02:50 UTC. Release notes for 2.1.27, 2.1.28, and 2.1.29: https://launchpad.net/mailman/2.1/2.1.27 https://launchpad.net/mailman/2.1/2.1.28 https://launchpad.net/mailman/2.1/2.1.29 Sanity checks on test mailing list shows mail is still flowing and archiving. Any questions or concerns, please let me know at this address or sysadmin(a)boost.org. Thanks, -- Brad Johnson Ciere Consulting 916.877.6030 brad.johnson(a)ciere.com ciere.com

1 0

[parameter_python] Merge to master
by Edward Diener 26 Oct '18

26 Oct '18

I would like to merge parameter_python to 'master' from 'develop'. Does anybody see anything wrong with this ? This fixes using Python 3+ with parameter as well as Python 2+, among other things.

3 4

Library devs only: Boost v2.x distro design questions
by Niall Douglas 26 Oct '18

26 Oct '18

Splitting this off from the other thread, can I get feedback from Boost library maintainers ONLY. Not users, not non-maintainers. Q0: Are you willing to do the work to adapt your library for any Boost v2.x distro if it were to happen? Q1: Would you prefer a new, separate Boost v2.x distro in parallel to the v1.x distro, or to keep everything within one v1.x distro? Q2: Would you be intending to keep your library inside Boost v1.x, move it exclusively to Boost v2.x, or have it exist in both Boost v1.x and v2.x but with different defaults configured? Also, would the version in v1.x be hard forked from any v2.x edition i.e. the v1.x edition would get orphaned? Q3: What C++ standard should Boost v2.x's master build system be defaulted to? C++ 11, 14, 17 or 20? Q4: Should Boost v2.x use a boost2 namespace, or namespace boost { inline namespace v2 { }}? (This affects whether Boost v2 and v1 editions of your library can be used within the same translation unit) Q5: What master buildsystem should Boost v2.x use? Boost.Build, cmake, Build2, something else? Q6: Should Boost v2.x's libraries auto integrate individually into some package manager? If so, which ones do you intend to support? Q7: Should Boost v2.x have official release versions done by release managers, or should it be a rolling release of "whatever last passed the CI @ 100%"? Note that you can have this, and have official release versions of "especially known good" editions too. Q8: Should Boost v2.x use a local HTML server to serve documentation, and the static HTML docs be dispensed with as a requirement? Q9: What are your feelings towards the use of Python to script infrastructure and tooling in any Boost v2.x? For example, Python to run a local HTML server to serve documentation locally, or Python to build a release etc Q10: What parts of core Boost are you utterly dependent upon, and would absolutely need ported to any Boost v2.x as no STL alternatives exist? I could go on, but let's stop there for now. Niall

12 16

[histogram] Objections against switch to C++14?
by Hans Dembinski 26 Oct '18

26 Oct '18

Dear reviewers of boost.histogram, thank you again for your reviews. I am currently working on the issues raised during the review and some of the requested features would be easier to implement when the library standard is raised from C++11 to C++14. This only affects the implementation side, not the user side. It would make my life easier and the implementation code more readable, because I can emulate `if constexpr` using in-place generic lambdas instead of out-of-place functors in the detail namespace. To make the library more user-friendly, I have to do more and more of these emulated `if constexpr`. Do you object against raising the requirement from C++11 to C++14 for the implementation of boost.histogram? Best regards, Hans

3 3

[smart_ptr] sharable_ptr any interest
by Marc Pawlowsky 26 Oct '18

26 Oct '18

I am working on a idea for a smart pointer called sharable_ptr. A cross between a unique_ptr and a shared_ptr. A sharable pointer has a single definite owner like a unique_ptr, and can be shared to other users similar to shared_ptr as a borrowed_ptr. However unlike a shared_ptr it is an error if the contents of the sharable_ptr go out of scope, by destruction or being reset or assigned, if there are still instances of a borrowed_ptr that reference it. The work is in its infancy at https://github.com/marcpawl/smart_ptr/tree/feature/leased_ptr with the documentation at https://github.com/marcpawl/smart_ptr/blob/feature/leased_ptr/doc/smart_ptr… >From the documentation: Motivation sharable_ptr, and its cohorts: sharable_ref, borrowed_ptr, and borrowed_ref are to help close the raw dangling pointer problem. Along with unique_ptr and shared_ptr, the number of C++ objects that will retain a raw pointer can be reduced. It will allow for easier reasoning of the lifespan of objects, and help catch errors where an object is referenced after it no longer should be. <https://github.com/marcpawl/smart_ptr/blob/feature/leased_ptr/doc/smart_ptr…> Analogy Marc owns a cottage on the lake and is willing to share it with his friends and family. He tells them to drop by anytime they want, even when he is not there. Amanda uses the cottage on a regular basis. Amanda also lets her friend Ava use it. Unfortunately due to a change in financial circumstances Marc has to sell the cottage. At this point neither Marc nor Amanda may use the cottage any more. In C++ terms, Marc has a sharable_ptr<Cottage>. When Amanda is at the cottage she has a borrowed_ptr<Cottage>, which she destroys when she leaves the cottage. When Amanda lets Ava use the cottage Ava gets a copy of the borrowed_ptr. Amanda and Ava must destroy their pointers prior to Marc releasing his. It would be an error for Amanda or Ava to retain a borrowed_ptr to the cottage even if she does not use it. Equivalent to retaining a copy of the keys. ## Alternatives Instead of using `sharable_ptr` and `borrowed_ptr`, you could use `shared_ptr` and `weak_ptr`. The error detection for a dangling pointer gets pushed to when the `weak_ptr` is locked to a `shared_ptr`, instead of when the owned object is freed. A possible advantage is that if the `weak_ptr` is not used then there is no error. The disadvantage is the code may have progressed quite a way before it is realized the referenced object no longer exists. Is there interest in this idea, should I keep working on it? I have so far only been working on Mac clang basement:smart_ptr marcpawl$ clang -v Apple LLVM version 10.0.0 (clang-1000.10.44.2) Target: x86_64-apple-darwin17.7.0 Thread model: posix Thanks Marc Pawlowsky

2 1

interest in a flag library
by Marc Pawlowsky 26 Oct '18

26 Oct '18

You should take a look at https://www.youtube.com/watch?v=1fwbG5TyI18 CPPCON 2018 session https://cppcon2018.sched.com/event/FnKQ/avoiding-disasters-with-strongly-ty… Arno Lepisk <https://cppcon2018.sched.com/speaker/arno_lepisk> Avoiding Disasters with Strongly Typed C++ I think the technique he describes is what you are looking for.

1 0

[c++ question] detecting reference to temporaries
by Raffi Enficiaud 25 Oct '18

25 Oct '18

I have a stupid question related to a bug in boost.test. A piece of code is doing something like: const value& get() { return *internal_iterator; // can be a ref or not to value or another type } The fix is trivial, *but* I want to test it. Is there any technique that would let me test for reference to temporaries? The only option I see would be to promote compiler warnings into error, but maybe there is something there? Thanks, Raffi (complete example here: https://github.com/boostorg/test/blob/90d577a620e008417af79f5caa25e701eef95… )

2 1

[boost.random] Library maintenance
by Nikita Kniazev 25 Oct '18

25 Oct '18

Random library has multiple PRs that hang for a long time already. Some of them address warnings that poisons its usage and maintenance of other libraries. Please consider placing Random under CMT. https://github.com/boostorg/random/pull/35 https://github.com/boostorg/random/pull/26 https://github.com/boostorg/random/pull/31

1 0

Re: [boost] [c++ question] detecting reference to temporaries
by Nikita Kniazev 25 Oct '18

25 Oct '18

> Is there any technique that would let me test for reference to > temporaries? The only option I see would be to promote compiler warnings > into error, but maybe there is something there? AddressSanitizer with -fsanitize-address-use-after-scope https://github.com/google/sanitizers/wiki/AddressSanitizerUseAfterScope

1 0

Boost 2 and build2
by Boris Kolpackov 25 Oct '18

25 Oct '18

I've noticed the discussion on Boost 2 where build2 was mentioned as one of the potential build systems. So I wanted to say that we would be happy to help on our side with any questions, missing features (like exporting targets in a CMake-compatible manner, as mentioned by Niall), etc. Also a couple of additional points about build2 that I think could be relevant to Boost 2 (or 1): 1. It is currently the only build system that I am aware of that has support for C++ modules (currently TS but we are tracking the standardization/implementation progress closely; see [1] for details). Now that modules are likely to be in C++20 I think this should be at least a consideration for Boost 2. 2. We have a public CI service[2] for open source project that I think could be quite useful to Boost. It might not currently be as extensive as Boost's (see [3] for the currently offered build configurations) but we are continuously expanding it plus Boost can run its own build machines with additional configurations. 3. build2 comes with a package manager[4] and Boost could take advantage of that by either publishing to cppget.org or running its own package repository (or both). I am happy to answer any questions here (if appropriate, of course), on the build2 mailing list[5], or on the #build2 slack channel[6]. [1] https://build2.org/build2/doc/build2-build-system-manual.xhtml#cxx-modules [2] https://ci.cppget.org [3] https://ci.cppget.org/?build-configs [4] https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml#guide-… [5] https://lists.build2.org/ [6] https://cpplang.slack.com/app_redirect?channel=build2

1 0

The future and present of Boost
by Robert Ramey 25 Oct '18

25 Oct '18

This was on another thread. Someone mentioned that it should be on it's own thread so here it is (slightly amended for context). For some time I've been concerned about the future of Boost as an organization. Here are the concerns I have: a) With C++11, the standards committee accepted a large portion of Boost into the standard. This left it unclear as to what the future value of Boost to C++ might be. b) The standards committee has ramped up it's efforts to include library proposals directly into the standard - thus side stepping the traditional requirement of "standardizing established practice". So this has left Boost, which helps to evolve "establish practice" outside of the development of the C++. An example of this has been the Ranges library which as been designed and developed totally within confines of the C++ standards committee. This effectively marginalizes Boost - that is, makes it less relevant and important. c) This effort by the committee is basically failing. It's creating the possibility that C++ will evolve into an ever larger and incomprehensible bag of disjoint features than it already is. It makes it much harder to learn C++. This puts C++ on a slow train to oblivion. This is not unusual with successful projects which expand their scope - as the committee has done. It's especially common for organizations run as a committee. Think large corporations: Kodak, Sears, All government organizations, universities - etc. All one has to do to see this is look at the papers list for the San Diego meeting. Also look at P0977r0. Consider that it take the committee 10 years for a proposal to evolve into something that can be delivered to users. It even takes 10 years to include something which is already in use by 100's of thousands of programmers - ASIO. Of course the C++ committee won't address the situation. Committees don't do that. They think they can remain relevant by expanding scope. and lo and behold, now they want to expand scope again to include tooling. Wake up and smell the coffee people. Learn to prioritize and limit the scope of your actions to that which only you can do. This would be better for C++. Do less - get more done! d) Boost can accept, review and deliver a new library in a year. Hence Boost has a reason to continue and exist. But Boost is also a committee - albeit a better designed one. It has to evolve as well. I think it can evolve if we continue to work on the stuff we've been successful at while at the same time experimenting with new ideas. Robert Ramey

23 70

warning: non-free usage requirements <threading>multi ignored
by blubee blubeeme 25 Oct '18

25 Oct '18

Hello I am trying to build boost from git clone I run bootstrap.sh with these flags ```shell ./bootstrap.sh \ --prefix=/usr/local \ --with-toolset=clang \ --with-icu=/usr/local \ --with-python=python27 \ ``` After boostrapping I append ```shell "using mpi ;" >> ./project-config.jam ``` There's two issues with that 1)icu isn't found even though icu headers are in /usr/local/unicode/ 2)I get this this warning ```error warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi_python at libs/mpi/build/Jamfile.v2:144 ``` Which I tracked down to this issue: http://boost.2283326.n4.nabble.com/explicitly-specified-values-of-non-free-… That thread leaves the issue unresolved and just throws a warning instead of failing. ```shell ./bjam \ --prefix=/usr/local \ --layout=system \ -d4 \ --toolset=clang \ --build-dir=./build \ --stagedir=/opt/boost \ -j4 \ include=/usr/local/include/unicode \ link=shared \ threading=multi \ stage \ ``` bjam output ```shell Performing configuration checks - default address-model : 64-bit - default architecture : x86 - symlinks supported : yes - C++11 mutex : yes - lockfree boost::atomic_flag : no - Boost.Config Feature Check: cxx11_auto_declarations : yes - Boost.Config Feature Check: cxx11_constexpr : yes - Boost.Config Feature Check: cxx11_defaulted_functions : yes - Boost.Config Feature Check: cxx11_final : yes - Boost.Config Feature Check: cxx11_hdr_mutex : yes - Boost.Config Feature Check: cxx11_hdr_tuple : yes - Boost.Config Feature Check: cxx11_lambdas : yes - Boost.Config Feature Check: cxx11_noexcept : yes - Boost.Config Feature Check: cxx11_nullptr : yes - Boost.Config Feature Check: cxx11_rvalue_references : yes - Boost.Config Feature Check: cxx11_template_aliases : yes - Boost.Config Feature Check: cxx11_thread_local : yes - Boost.Config Feature Check: cxx11_variadic_templates : yes - has_icu builds : yes warning: non-free usage requirements <threading>multi ignored warning: in main-target mpi at project-config.jam:42 warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi at libs/mpi/build/Jamfile.v2:119 - zlib : yes - bzip2 : yes - lzma : yes - zstd : no - iconv (libc) : yes - icu : no - icu (lib64) : no - xlocale supported : yes - native-atomic-int32-supported : yes - native-syslog-supported : yes - pthread-supports-robust-mutexes : yes - compiler-supports-ssse3 : yes - compiler-supports-avx2 : yes - gcc visibility : yes - long double support : no warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi_python at libs/mpi/build/Jamfile.v2:144 - libbacktrace builds : no - addr2line builds : yes - WinDbg builds : no - WinDbgCached builds : no - BOOST_COMP_GNUC >= 4.3.0 : no Component configuration: - atomic : building - chrono : building - container : building - context : building - contract : building - coroutine : building - date_time : building - exception : building - fiber : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - stacktrace : building - system : building - test : building - thread : building - timer : building - type_erasure : building - wave : building ``` I do have a working installation of openmpi installed in /usr/local and mpicxx is in my path from following the directions here: https://www.boost.org/doc/libs/1_64_0/doc/html/mpi/getting_started.html#mpi… in the end the build errors out ```shell 0.003049 sec system; 0.000000 sec user; 3.078255 sec clock Using shell: /bin/sh -c argv[0] = '/bin/sh' argv[1] = '-c' argv[2] = ' ln -f -s 'libboost_wave.so.1.69.0' '/wrkdirs/usr/ports/devel/boost-devel/work/stage/lib/libboost_wave.so' ' ln-UNIX /wrkdirs/usr/ports/devel/boost-devel/work/stage/lib/libboost_wave.so ln -f -s 'libboost_wave.so.1.69.0' '/wrkdirs/usr/ports/devel/boost-devel/work/stage/lib/libboost_wave.so' 0.001905 sec system; 0.000000 sec user; 1.957884 sec clock ...failed updating 86 targets... ...skipped 17 targets... ...updated 1147 targets... *** [do-build] Error code 1 make: stopped in /usr/ports/devel/boost-devel 1 error ``` two questions: 1) How do I solve the non-free usage requirements warning 2) Why isn't icu being picked up? github issue:: https://github.com/boostorg/boost/issues/210

1 0

Library devs only: Boost v2.x distro design questions
by Niall Douglas 24 Oct '18

24 Oct '18

Splitting this off from the other thread, can I get feedback from Boost library maintainers ONLY. Not users, not non-maintainers. Q0: Are you willing to do the work to adapt your library for any Boost v2.x distro if it were to happen? Q1: Would you prefer a new, separate Boost v2.x distro in parallel to the v1.x distro, or to keep everything within one v1.x distro? Q2: Would you be intending to keep your library inside Boost v1.x, move it exclusively to Boost v2.x, or have it exist in both Boost v1.x and v2.x but with different defaults configured? Also, would the version in v1.x be hard forked from any v2.x edition i.e. the v1.x edition would get orphaned? Q3: What C++ standard should Boost v2.x's master build system be defaulted to? C++ 11, 14, 17 or 20? Q4: Should Boost v2.x use a boost2 namespace, or namespace boost { inline namespace v2 { }}? (This affects whether Boost v2 and v1 editions of your library can be used within the same translation unit) Q5: What master buildsystem should Boost v2.x use? Boost.Build, cmake, Build2, something else? Q6: Should Boost v2.x's libraries auto integrate individually into some package manager? If so, which ones do you intend to support? Q7: Should Boost v2.x have official release versions done by release managers, or should it be a rolling release of "whatever last passed the CI @ 100%"? Note that you can have this, and have official release versions of "especially known good" editions too. Q8: Should Boost v2.x use a local HTML server to serve documentation, and the static HTML docs be dispensed with as a requirement? Q9: What are your feelings towards the use of Python to script infrastructure and tooling in any Boost v2.x? For example, Python to run a local HTML server to serve documentation locally, or Python to build a release etc Q10: What parts of core Boost are you utterly dependent upon, and would absolutely need ported to any Boost v2.x as no STL alternatives exist? I could go on, but let's stop there for now. Niall

2 4

Re: [boost] [release] 1.69.0 deadline for new libraries approaching
by Peter Dimov 24 Oct '18

24 Oct '18

> Robert Ramey wrote: > > On 10/22/18 10:19 AM, Peter Dimov via Boost wrote: > > > Marshall Clow wrote: > > > > > >> * 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes > > > > > > OK... do we want CMake config files installed by 1.69 or not, then? > > > > I'd like to know this as well. If so, I presume that we can consider > > the Boost/CMake issues resolved and we can just move on from this? > > I doubt it. The CMake issue is much bigger than this. To expand on that: The Boost/CMake issues concern four scenarios: 1. CMake users who want to use a pre-built Boost from CMake, after installing it either with `b2 install`, as usual, or via some other mechanism; 2. CMake users who want to use Boost (or an individual Boost library) from CMake without building it with b2 and installing it, but as a subproject, built by CMake; 3. Building and installing Boost with CMake, replacing the current Boost.Build building/installing infrastructure; 4. Testing Boost with CMake, replacing the current Boost.Build testing infrastructure. Installing CMake config files as part of `b2 install` falls into scenario number 1. Boost is still built with Boost.Build as always, it's just that in addition to libboost_foo.a, the user also gets libboost_foo.cmake, which allows him to do `find_package(boost_foo)` from his CMakeLists.txt file. Nothing more than that. This doesn't affect, doesn't target, and doesn't address, scenarios 2-4 at all.

8 25

boost-cmake and quickbook
by Raffi Enficiaud 23 Oct '18

23 Oct '18

On 23.10.18 21:29, Edward Diener via Boost wrote: > On 10/23/2018 2:36 PM, Robert Ramey via Boost wrote: >> On 10/23/18 11:17 AM, Peter Dimov via Boost wrote: >>> Robert Ramey wrote: >>> >>>> And I place the html and pdf versions into the repo so users don't have to build it. >>> >>> Placing the .html/pdf files into the repo is one - unquestionably modular - way to do it, but it does have its downsides. >> >> Both true. >> >> downside >> - "wastes" a lot of space >> - redundant - docs could get out sync with the code. >> >> >> upside >> >> - current documentation is always available to the user. In the two libraries of mine - documentation is an important part and I don't think the either would be usable without them. >> - only needs to be built on one machine no hassle for users >> - document build doesn't have to be "portable" >> - potential users can easily browse the documentation before they clone/download the package. This works well with github. I think this is very valuable - especialy for safe_numerics which most people don't actually see the need for. Call it a sales tool. > > I am sure you know that github already has support for viewing the documentation via the github io mechanism, so your last '-' item is not really applicable to your argument. > > My argument is simply that lots and lots of libraries use Boost Build to generate the docs, very often through the quickbook -> docbook -> pdf/html mechanism and unless we are going to continue to do it that way when Boost uses CMake we will eventually need a way to duplicate the Boost Build mechanism for creating the docs in CMake. > > Nonetheless I continue to believe that the move to CMake by Boost should be achieved in small steps, so that we can assure success in one step for all libraries before we even think about attempting the next. I still have the same fear that trying to accomplish everything at one time will mean that nothing really will ever get done. I only added item 5) to Peter's list because that is something we will eventually have to decide about. [sorry for multiple posting] Talking about small steps, feel free to copy paste this wherever you need it: https://github.com/raffienficiaud/boost-cmake/blob/master/boost-cmake/quick… I compiled Boost.Test documentation with this, this is fully cmake and it does the catalog generation on the fly. This is a small step, usually this is where collaboration starts, since I do not have all the knowledge of quickbook/docbook nor the bandwidth ATM. *But* if somebody is kind enough to assist me on this, in particular explaining me if we would want --stringparam chunk.first.sections "1" --stringparam chunk.section.depth "4" --stringparam generate.section.toc.level "3" --stringparam html.stylesheet "boostbook.css" --stringparam toc.max.depth "3" --stringparam toc.section.depth "10" to be exposed when compiling a documentation, or how to run the doxygen part, then porting things to cmake will be definitely faster. Raffi _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[preprocessor] vc++ using the experimental preprocessor
by Edward Diener 23 Oct '18

23 Oct '18

I have updated on the 'develop' branch Boost PP code that will use the vc++ C++ standard conforming preprocessor in VS2017 15.8 and above, as explained at https://blogs.msdn.microsoft.com/vcblog/2018/07/06/msvc-preprocessor-progre…. The code essentially treats vc++ in this mode as a strictly standard conforming preprocessor. There is the switch of /experimental:preprocessor which turns on the new preprocessor for the end-user, else the normal non-standard vc++ preprocessor is still the current default. BTW I tried to post a comment to the link above, explaining that the test posted in the article for the new preprocessor was wrong, but for whatever reason it never was actually posted as a comment. Nonetheless I got it right for myself in the Boost PP code in its config.hpp, so I am not going to worry about the fact that others may use the erroneous test in the article in their code. The change I made to Boost PP does not affect any other compiler, including vc++ in normal non-standard preprocessor mode. I have no idea if any regression tests for msvc-14.1 are made with this /experimental:preprocessor switch, but I will wait for 'develop' to cycle through before merging to 'master' in Boost PP. My preprocessor tests show four failures with the new vc++ preprocessor. Two of the failures are based on the fact that the test code expects a macro called with the wrong number of arguments to produce a compiler error and not just a warning. But since I have been told, vis-a-vis the same situation occurring for the Oracle C ++ compiler, that compilers are allowed under the C++ standard to produce a warning and just "chug" on, even if producing macro output that is certainly not what the programmer intended, rather than produce a compilation error maybe I just need to eliminate those tests, as important as I think they are. The other two failures are with the BOOST_PP_ITERATE macro and corresponding structures. The new preprocessor also erroneously continues to give a number of argument mismatch warnings in cases where it does not really exist, similar to the non-standard preprocessor, but since it "chugs" on despite the false warnings it ends up producing the correct output anyway. I have already posted a bug report about the fact that the new preprocessor gives a warning and continues when a macro is called with the wrong number of arguments. The other problem with BOOST_PP_ITERATE will be harder to determine because the iterate mechanism in Boost PP is fairly complex and I will need to figure out what is causing it and reduce the failure to a much simpler form in order to report it. As far as the compiler warnings of the wrong number of arguments when they do not exist, again I will have to try and figure out why and report the bug(s) to Microsoft. If anyone wants to try this out on Boost PP 'develop' feel free to do so. You will need to invoke the msvc-14.1 toolset in Boost Build with the /experimental:preprocessor switch and you will need to upgrade VS2017 to 15.8 or above. You can tell whether you have succeeded invoking the Boost PP tests with the new preprocessor by looking at the run output of the config_info test. If the BOOST_PP_CONFIG_FLAGS() is 0x0001 it is the new preprocessor, else it is the default non-standard preprocessor (0x0004).

6 13

Invitation to join the C++ chat community!
by Vinnie Falco 23 Oct '18

23 Oct '18

All: Hi there. I would like to personally invite all of the Boost authors, participants on the mailing list, and interested parties to join the most popular C++ Slack workspace, where many lively technical discussions related to C++ and its ecosystem take place. There are channels for everyone, especially the #boost channel, but also channels for WG21 committee discussions such as #future_standard and #wg21. There's even an #sg14 ! You can learn more and request a free invitation here: <http://slack.cpp.al> This workspace is sponsored by the C++ Alliance, a non-profit organization which promotes and advances the C++ language and provides educational resources. Find out more about the Alliance here: <http://cpp.al> Regards

3 5

Development Calendar is empty
by James E. King III 23 Oct '18

23 Oct '18

When is the next freeze or release? https://www.boost.org/development/index.html - Jim

5 5

[histogram] Finalising version for submission
by Hans Dembinski 22 Oct '18

22 Oct '18

Hi all, I have a general question regarding the submission process on how to deal with extensions of the library. I am currently working on the points raised in the review. Clearly, the bugs need to be fixed and the documentation improved where it was lacking. So the procedure is clear in that regard, but the final version to be included in Boost will also have more features, the main ones are: - support for profiles and in general arbitrary accumulators as bin "counter" types - in particular any Boost.Accumulator - allow arbitrary metadata (or no metadata at all) to be associated with the builtin axes types, instead of just supporting a string label (the metadata type will be a template parameter) - use axis types through a traits-interface to make adding custom axis types really easy (a minimal axis only needs to implement `int operator()(something) const` and `unsigned size() const`, everything else is optional) - use storage types through a traits-interface to allow arbitrary STL and Boost containers as storage backends - add a support library for typical calculations done with histograms, like reducing a high-dimensional histogram to a lower-dimensional histogram, shrink an axis, etc - growing axes that increase the number of bins while the histogram is filled I started working on these features and switching to C++14 would simplify the implementation a lot, thanks to generic lambdas and return type deduction. So I would like to raise the requirement for the final library from C++11 to C++14. Since these are substantial changes, is another formal review of the final version required? In any case, I will request informal feedback on the final version on the list before histogram is released with Boost for the first time. Best regards, Hans

5 10

[all] Hidden visibility is on by deafult
by Antony Polukhin 22 Oct '18

22 Oct '18

Good news everyone! I'd like to announce that now Boost libraries are build with hidden visibility by deafult. Many thanks to Andrey Semashev for providing the required patches and PR to fix some builds, and to Glen Fernandes for merging. Separate thanks to all the Boosters who reported/fixed visibility related issues.

3 2

[review][histogram] Histogram Review Results
by Mateusz Loskot 22 Oct '18

22 Oct '18

Hi Everyone, Please, welcome the Histogram library to the Boost collection! Thank you Hans for submitting a high-quality library for review. Thank you to the reviewers as well as those who just exchanged their comments on numerous aspects of the library and participated in the fruitful discussions. Among reviewers, we can recognise veteran Boost contributors and authors as well as experts in the fields of statistics, raster analysis, including authors of histogram-oriented software packages. ---------------------------------------- Official reviews and votes: ---------------------------------------- 1. Klemens David Morgenstern - ACCEPT 2. Jim Pivarski (off-list) - ACCEPT 3. Bjorn Reese - ACCEPT conditionally 4. Steven Watanabe - ACCEPT conditionally 5. Alex Hagen-Zanker - ACCEPT Non-review participations: 1. Andrea Bocci (off-list) 2. degski 3. Glen Fernandes (off-list) 4. Gavin Lambert 5. Seth 6. Mateusz Loskot ---------------------------------------- Acceptance conditions ---------------------------------------- Two reviews stated conditions which are important fulfilled: Bjorn Reese - Reference documentation is finalized Steven Watanabe - Various exception safety and memory issues must be fixed. - The reference documentation must be completed. Specifically, various preconditions, requirements, and assumptions must be made explicit. I believe those are not controversial at all and Hans is also interested in addressing those requests. ---------------------------------------- Concerns and comments ---------------------------------------- Jim Pivarski mentioned importance of profile plots as fundamental enough that they should be part of the feature set. In short term, the profile plots can be implemented as a new storage type, using the extension capabilities. Similarly, some concurrent applications would need atomic-valued bins, but these, too, can be storage types. Bjorn Reese pointed out some aspects of the design that makes the library not work very well with STL algorithms. Bjorn strongly recommended that the default storage policy is changed to remove some of those limitations. Steven Watanabe provided Hans with large number of very detailed comments and fixes (eg. do not call destructor which has been fixed), suggestions how to improve run-fail tests and serialization tests. Alex Hagen-Zanker commented that range-based for-loops support could be improved, suggested to provide separate ranges or views for certain histogram access scenarios. Another important theme of Alex' review was Histogram applicability for moving window type analysis. Then, Alex requested clarification on choosing variance based on the Poisson distribution instead of the binomial distribution. degski suggested to look for some "low hanging fruits" in C++14 and/or C++17, the library could potentially benefit from, pushing the 'modern C++' trait of the library even further. Gavin Lambert suggested to allow use of quantity types like Boost.Units. Glen Fernandes mentioned he would raise allocator model support issues or relaxing the requirement that the pointer must be a raw pointer of type value_type*. Glen mentioned he may even be available to help. Hans has already addressed many of the suggestions and issues or planned related features for future releases of the library. Issues resulting from the feedback received during the review can be tracked and further discussed on GitHub, labelled with boost-review: https://github.com/HDembinski/histogram/labels/boost-review ---------------------------------------- The Upsides ---------------------------------------- There were lots of great things said about the Histogram library: - design: excellent, clean, simple and extensible in principle - useful and well-designed features - geared towards readability and performance - very good documentation ---------------------------------------- Final Thoughts ---------------------------------------- Reviewers are worth their weight in gold nowadays. Once again, I'd like to thank all participants for great amount of quality feedback that already led to important improvements in the Histogram library in very timely manner - thank you Hans! The Histogram library is a valuable addition to Boost. Best regards, -- Mateusz Loskot Review Manager for the proposed Boost.Histogram

2 1

Re: [boost] Mail List Migration - Update
by Tom Kent 21 Oct '18

21 Oct '18

> > The Boost mail lists are now migrated to a new set of servers. > This change affected all mail lists and web resources (signing up, > changing passwords, moderator access, archives...) that were associated > with the domain lists.boost.org . > If you are having difficulties, please drop me an email. (Oh the irony) > Happy coding! > michael > -- > Michael Caisse > Ciere Consulting > ciere.com Michael- I've tried to send e-mail to a couple lists with boost over the past few days. On Tuesday, Oct 16, I sent an e-mail at 19:21 CDT to the boost(a)lists.boost.org list, "Non-ASCII Path Names in Repo" [1]. It seemed to take the better part of a day to be received by the list. I remember it taking a long time (>24hrs), but I can't prove that. However, if you click the previous message/next message links on [1], you'll see that both of those messages (including the one previous!) are timestamped several hours after mine. Now, as of Friday, Oct 19, at 06:59 CDT I had sent another e-mail, this time to boost-testing(a)lists.boost.org. As of writing this e-mail (07:35 CDT, Sunday Oct 21), it still hasn't shown up on the testing list [2], and I haven't received an e-mail saying that it was received by the list. Any thoughts as to what might be happening here? In the past (including earlier this month for boost-testing), I was able to post without issue from this address (lists(a)teeks99.com) to both of these lists. Thanks, Tom [1] https://lists.boost.org/Archives/boost/2018/10/243784.php [2] https://lists.boost.org/boost-testing/2018/10/index.php

1 0

Allow LICENSE file per a library repository (PR #374)
by Mateusz Loskot 21 Oct '18

21 Oct '18

Hi, I'd like to bring this proposal to the community's attention: https://github.com/boostorg/website/pull/374 BTW, from time to time, while I looking at various requirements I try to refresh those outdated and catch up with the reality. I take baby steps. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Re: [boost] Fwd: Installing CMake configuration files
by Peter Dimov 20 Oct '18

20 Oct '18

Steven Watanabe wrote: > Just a couple comments: ... > * I'm not fond of the ROOT parameter for boost-install.boost-install. > * Dependencies can be referenced with /boost/$(deps)//[stage|install] > * You can find the full path to the boost-install.jam with > [ path.root [ modules.binding $(__name__) ] [ path.pwd ] ] > This avoids hard-coding the location of boost_install relative > to the superproject. Actually, [ modules.binding $(__name__) ] seems to return an absolute path, so path.root/path.pwd may not be needed here? boostcpp.jam does BOOST_ROOT = [ modules.binding $(__name__) ] ; BOOST_ROOT = $(BOOST_ROOT:D) ; which kind of implies that it relies on getting the absolute path. > * That just leaves the stage directory, which is tied to the > project root, and should perhaps be calculated in Jamroot > instead of in boost_install. The stage directory needs to be retrieved from boostcpp, but boostcpp just sets it to "stage", which only works from top-level. It should probably use $(BOOST_ROOT)/stage, and then other modules can peek for it. There are other things that are needlessly replicated - install-header-subdir, install-default-prefix. All of these need to be peekable from a canonical location. > * This seems to handle --layout=versioned, but I'm not clear on > how well it handles --layout=system where we expect to use a > single compiled library for all configurations. It worked when I tried it. Note that you can have two libraries with --layout=system, not just one; libfoo.a and foo.so. > * Are the error messages that you get from CMake when there > isn't a configuration that matches the request intelligible? Not very. There's Boost_DEBUG, which tells you why something was skipped, but ideally, it needs to detect the case when no variant matched, and _then_ tell you why things were skipped without your having to set Boost_DEBUG beforehand. I haven't gotten that far yet; usability can be improved once we have it working. > It looks like the target will exist but will silently do nothing? Yes, you get a link error. > What if something goes wrong and there are multiple matches? I haven't encountered this so far :-) although it's possible in principle because at the moment I ignore some "non salient" properties. > * If generate-cmake-config takes the library as a source, > then it's possible to derive both the library dependencies > and the exact library name from the library target. The > dependencies can be found at the virtual target level in > generate-cmake-config, and the exact file name will appear > as the source in generate-cmake-config-. Doing it this way > also has the side effect that the CMake configuration won't > be installed if the library fails to build, which may be a > good thing. These may take me a while to figure out. :-)

3 15

[asio] Issues piling up
by Vinnie Falco 20 Oct '18

20 Oct '18

There are issues which are years old which have been lingering in the Boost.Asio repository, and there are also old issues in the stand-alone Asio repository. It seems like these are being ignored, is there any strategy for addressing this? Examples: This one is going on a year: <https://github.com/boostorg/asio/issues/77> Two years: <https://github.com/chriskohlhoff/asio/issues/124> Thanks

10 16

Re: [boost] Fwd: Installing CMake configuration files
by Peter Dimov 20 Oct '18

20 Oct '18

> Yeah, I haven't been able to figure this part out. How do I pass the > $(sources) from generate-cmake-variant to generate-cmake-variant-'s > sources? The sources - in this case $(lib-target) go here, after `non-scanning-action`: local a = [ new non-scanning-action $(lib-target) : boost-install.generate-cmake-variant- : $(property-set) ] ; :-)

1 0

Installing CMake configuration files
by Peter Dimov 19 Oct '18

19 Oct '18

I've taken another stab at installing CMake configuration files along with the libraries in `b2 install`. CMake configuration files are .cmake files, typically installed into $prefix/lib or $prefix/lib/cmake, that allow f.ex. `find_package(boost_system)` in a CMakeLists.txt file to find the installed Boost.System library and declare a CMake target Boost::system that refers to it. CMake targets can then link to Boost::system and all is well. The work in its current state is available on the feature/cmake-config branch of the superproject: git clone --recursive -b feature/cmake-config https://github.com/boostorg/boost cd boost bootstrap b2 --prefix=... install After that .../lib should contain the libraries and .../lib/cmake - the config files. Then from CMake cmake -DCMAKE_INSTALL_PREFIX=... .. as usual. See for example the test scripts at https://github.com/boostorg/boost_install/blob/master/.travis.yml#L60 and https://github.com/boostorg/boost_install/blob/master/appveyor.yml#L40 Since `b2 install` installs more than one library variant, the CMake configurations need to pick the correct one and to do so look at (a subset of) the FindBoost-compatible variables as described at: https://github.com/Kitware/CMake/blob/master/Modules/FindBoost.cmake#L122 Boost_USE_DEBUG_LIBS, Boost_USE_RELEASE_LIBS, Boost_USE_STATIC_LIBS, Boost_USE_STATIC_RUNTIME, Boost_COMPILER, Boost_DEBUG are honored and have the same meaning as in FindBoost. Boost_USE_MULTITHREADED and Boost_USE_DEBUG_RUNTIME are presently ignored, but probably shouldn't be. :-) The default of Boost_USE_STATIC_LIBS being OFF is a bit inconvenient on Windows, where without `--build-type=complete` our installation only gives you static libraries, and there are suggestions to respect it being ON or OFF, but when not set, to look at BUILD_SHARED_LIBS instead. Under the hood this represents a refactoring of the current centralized installation approach in which the superproject staged and installed the libraries on `b2 stage` and `b2 install`. Now the top level stage and install targets just delegate to each library's stage and install targets, which are responsible for staging/installing that particular library, its CMake config, and its dependencies. These library-level stage and install targets are created by the helper b2 rule boost-install, which already existed (in Jamroot), but is now much enhanced and lives in its own module tools/boost_install. In addition, a metalibrary libs/headers is introduced, which corresponds to the headers as present in a release (in subdirectory boost/) or as installed by `b2 install`. Its install target, in fact, installs the headers, and its stage target, currently empty, should probably assume the function of linking the headers (which at the moment also lives in Jamroot.) At some future point, when we decide to switch to releasing the headers in their original libs/$lib/include locations, the install target of a library will just copy that library's headers; but we aren't there yet. The header-only libraries are used from CMake by finding the package boost_headers and linking to the target Boost::headers. I've deliberately not done anything about Boost::boost and find_package(Boost), to allow FindBoost.cmake to delegate to the config files if present (when Boost 1.69/1.70 or higher is installed), while preserving backward compatibility (when 1.68 or lower is installed.)

6 13

test message - please ignore
by Robert Ramey 19 Oct '18

19 Oct '18

just to see if my newsgroup interface is working. Robert Ramey

1 0

[python] Checking Python version
by Edward Diener 18 Oct '18

18 Oct '18

How do I check the Python major version in code when using Boost.Python ? I know there is a way to do it through a preprocessor define by including the CPathon patchlevel.h file but I would rather not include low-level Python files if Boost.Python has some way of doing it.

2 1

[test] How to execute shell commands
by Mike Dev 18 Oct '18

18 Oct '18

As an extension to my previous question: Does the boost test framework provide an integrated mechanism to get the binary directory (the directory where the currently running test executable is placed) and/or the source directory (where the jam-file resides that defined the test)? Best Mike

4 5

[intrusive] static_assert(sizeof(caster)==sizeof(int))
by Vinnie Falco 18 Oct '18

18 Oct '18

A user is reporting a static assert on compilation: <https://github.com/boostorg/beast/issues/1270> Any ideas? Thanks

2 1

Boost header isolation testing
by James E. King III 16 Oct '18

16 Oct '18

In the winapi project there's a neat little Jamfile rule that will ensure each public header will compile properly (i.e. it is not missing any #include statements). I pulled this into uuid when I started maintaining it, and I find myself pulling it into another repository. It would be nice to have this as a standard Boost.Build rule that one could easily add to test Jamfiles. Is there anything like this that exists right now in Boost.Build? - Jim

6 9

Boost CMake support - Request for Comment
by Robert Ramey 16 Oct '18

16 Oct '18

Background ========== My personal knowledge of build systems is somewhat limited. a) I don't really understand CMake all that well. I have made CMakeLists.txt files for both the serialization library and the safe numerics libraries as an aid to build and maintain IDE and make files used in running tests and posting results to CDash. b) I don't really understand our current system, Boost Build, very well either. I've made jam files for building and running tests for the serialization and safe numerics libraries. c) I recently reviewed C++Now 2017: Daniel Pfeifer's excellent video from C++Now 2017 “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk . I recommend it highly. Despite my lack of knowledge in this area, or perhaps because of it, I've volunteered to direct the effort to evolve Boost so that users of Boost can avail themselves of the benefits of CMake. This effort will be organized as follows: a) A discussion on the boost developers mailing list with the goal of reaching a consensus as to what benefits CMake can and should provide to users and developers of Boost. This effort will commence with the posting of this notice. I hope that this discussion can be more or less resolved within 30 days. b) I will then synthesize from the above discussion a call for proposals which lists the requirements and requirements. c) Those proposing CMake for boost will have approximately 90 days to prepare their proposals. Their proposal are expected to look similar to a boost library proposal. That is they are expected to have some (CMake) code, along with tests, documentation including tutorials and reference. This is only an expectation. It's conceivable that such a proposal might only contain conventions and and samples of what boost library should contain to fulfill the requirements. As with boost libraries, submissions are not required to totally complete. But they have to be sufficiently complete to convince reviewers the the submission fulfills the stated requirements and can be finished in good time. d) After the 90 day period, submissions will be reviewed simultaneously. Note that this is at a variance from normal boost procedure of reviewing submissions one at a time. Since we expect to receive a number of submissions and only one can be accepted, the normal boost protocol can't really function. Target date for this review is 1 February 2019. e) After the review period the review manager will prepare a report which includes the decision of which submission will be accepted into the official boost distribution. Currently, I, Robert Ramey, expect to be review manager. However, it's possible that this by the time the review is undertaken, this coveted position could be assigned to some more worthy candidate. Scope, Requirements and Features ================================ We presume that submissions will fulfill the applicable requirements of any boost submission. In addition we would like to see the following addressed. Library Build ------------- “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk Recommends that all libraries - including header only libraries have a CMakeList.txt file. What should this include for Boost Libraries? Library Test ------------ Should facilities for "testing" be only done by developers? or should users who acquire library packages also be able to test libraries. Should CMake testing results posting be used - CDASH? Should we just skip the issue of Library Testing and continue to depend on Boost Build. Library Packaging ----------------- Is the library packaging facility provide by CMake - CPACK - useful to boost. Should boost libraries be updated to support it? Dependencies ------------ If the above is implemented, can we depend upon CMake to handle library dependencies? Or does some special functionality Do circular dependencies constitute a problem? Modularity ---------- Currently boost is organized as a tightly integrated group of libraries. This organization manifests itself in a number of ways. We have a Boost "super project" in github. Boost libraries are "sub projects" of this super project. This known structure is exploited by and depended upon by boost tools. Should CMake support continue this policy/design. We distribute boost as "super project". Should we continue to do this or distribute libraries on a library by library basis. Does CMake/CPACK etc. make this "simple"? Documentation/testing --------------------- What support should be require for uses of Boost CMake implementation. Documentation, examples, templates for helping library developers. How should the CMake design/implementation be tested? Other considerations -------------------- add your requirement/features here. Useful Resources =============== “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1 https://github.com/purpleKarrot/Boost.CMake https://www.youtube.com/watch?v=eC9-iRN2b04 Please try to keep this discussion on this list. I know that there has been a lot going on on slack. But having it in two places makes it harder for me to review and summarize. Also slack doesn't conveniently maintain comment hierarchy. So please try to keep this discussion on this list. Robert Ramey

15 47

Re: [boost] "peer reviewed" - Rights and responsibilities of maintainers
by Bjorn Reese 16 Oct '18

16 Oct '18

On 10/16/18 9:59 AM, Alexander Grund via Boost wrote: > So again: What is the Boost course on reviews of existing libraries and > the statement on the rights and responsibilities of maintainers? https://www.boost.org/community/reviews.html#Maintainer

4 4

[program_options] custom validator overrides
by Roger Martin 16 Oct '18

16 Oct '18

Hi, The Custom Validators documentation https://www.boost.org/doc/libs/1_68_0/doc/html/program_options/howto.html shows void validate(boost::any& v, const std::vector<std::string>& values, magic_number* target_type, int) { but the possible templates don't match; the last variable type is an int; the key is matching this last type: int goes with std::vector<T>* long goes with T* it also seems possible to hit the void validate(boost::any& v, const std::vector<std::basic_string<charT> >& s, boost::optional<T>*, int) { where it then calls for get_single_string and if you are trying for a multitokens switch args, it'll throw " only takes a single argument". which also varies if it was parsed by command_line_parser or parse_config_file command_line_parser: vector size can >= 1 up to number of switch args parse_config_file: vector size ==1 no matter what the number of args are on the input. just one string with all switch args. This was tested with 1.65 yet I don't see anything changing in https://github.com/boostorg/program_options/blob/develop/include/boost/prog…

2 1

[RFC] unique_val (handles, IDs, descriptors...)
by Miguel Ojeda 15 Oct '18

15 Oct '18

Hi all, While working on a medium-sized project, I had to wrap quite some handles, IDs, descriptors, etc. into RAII classes. Somehow, writing those and making them movable seemed more verbose than needed. I searched in the STL and Boost for something already implemented, but nothing seemed to come up. I decided to write my own prototype to see whether I was missing something important; but actually using it in my project felt quite natural and simple. At this point, I asked for a second opinion from a well-known expert (thanks Scott!) and he agreed that it seemed like a reasonable idea but, of course, he would also be surprised if others haven't come up with something similar. So I polished it up a bit and uploaded it to: https://github.com/ojeda/unique_val Below you have the introduction inlined [1]. If you have the time, please take a look (specially to the Rationale) and let me know your comments. The code itself is very short and straightforward. If you already have this class/template in Boost somewhere that I missed, please let me know! Otherwise, if you think this could be interesting to put into Boost in some existing library (not sure which) or as a new tiny library, I would be glad to make the effort to expand it, clean it up, etc. Thank you! Miguel [1] """ A single-header header-only library for representing unique values (handles, IDs, descriptors...) that default to a value on move for C++11, C++14 and C++17. It simplifies writing resource-owning classes (RAII) with move semantics support for resources with handles, IDs or descriptors that are supposed to be used as unique values, not as unique pointers. For instance, it can be used with non-pointer handlers (like the `int` file/socket descriptors in POSIX) and with opaque pointer handlers (like the `HWND` handles in the Win32 API). As such, it can be used as an alternative to `std::unique_ptr` with or without custom deleter, specially for resources that use a non-pointer type or resources that are not simply heap-allocated. It does not have any overhead compared to using the original type. It supports booleans, integers, pointers and enumerations. The default value can be different than the default-constructed value (i.e. different than 0, nullptr, etc.). """

7 13

bjam question about "requires" negation
by James E. King III 13 Oct '18

13 Oct '18

I want to run a test that should run without explicit operator conversion capability and fail to compile with explicit operation conversion capability, but I'm not sure how to negate the requires statement. I'm sure it's trivial but I found no examples. I tried a bunch of things but none worked. [ run implicit_conversion.cpp : : : [ requires NO cxx11_explicit_conversion_operators ] : implicit_conversion ] [ compile-fail implicit_conversion.cpp : [ requires cxx11_explicit_conversion_operators ] : explicit_conversion ] How do I properly implement the "NO" part? Thanks, Jim

2 1

[parameter] An offer to help maintain and improve the library
by Cromwell Enage 13 Oct '18

13 Oct '18

Hello, everyone. It took me a while to get around to this, but here goes. I've been a long-time user of Boost libraries, although life events imposed a bit of a hiatus until recently. But now I have the opportunity to help out some more, and one of the ways I want to give back to this community is by helping to maintain and improve Boost.Parameter. I participated in the review of this library before it was accepted, so I'm familiar with its capabilities and code structure. In addition to fixing any bugs and handling pull requests, I'd like to make the following improvements, which I will summarize here: * Add macros to generate Boost.Parameter-enabled function call operators. * Add parameter category qualifiers "consume", "move_from", and "forward". (Current qualifiers are "in", "out", and "in_out".) * Fix parameter::parameters::operator() so that it also accepts non-const rvalues. * Be no longer bound by BOOST_PARAMETER_MAX_ARITY on compilers that support perfect forwarding. * Enable parameter::template_keyword<> to accept function types. * Remove the necessity of wrapping boost::ref() around non-const lvalues. I can discuss each of these bullet points in separate threads if necessary. I await your feedback! Cromwell D. Enage

2 1

Boost xxhr ? High level http client library
by Damien Buhl 13 Oct '18

13 Oct '18

Dear Boost, I've built an header-only library based on Boost.Beast which allows you to perform HTTP requests. It is implememented with two backends : * Boost.Beast for native builds. * XmlHttpRequest for WebAssembly (plans to migrate to fetch API which is richer) Actually Boost.Beast is a great lib, however it's API is thought to build HTTP centric app not just to make some simple HTTP call ( as for example urdl was ). xxhr on the other hand is about making it simple to call an HTTP service. Usage example : GET <https://nxxm.github.io/xxhr/html/namespacexxhr.html#a69bafa24d7c33b004a7de8…>( "http://httpbin.org/anything"s, on_response = [](auto&& resp) { std::cout << resp.text; }); I would be really interested in a pre-review or some feedback about it's API. The implementation merits more attention and can significantly be improved but this email is to grab a first feedback from the community. Documentation : https://nxxm.github.io/xxhr/ GitHub : https://github.com/nxxm/xxhr Example code relying on it : nxxm/gh <https://github.com/nxxm/gh>: partial GitHub API implementation Thanks for your time :) -- Damien Buhl Software Developer +33 6 77 43 10 05 https://nxxm.github.io/

3 5

Test matrix file read errors?
by James E. King III 11 Oct '18

11 Oct '18

I'm trying to look at the develop test matrix for a couple repositories and I am getting an error: Error extracting file: Error code 9 - The specified zipfile was not found *(the > file exists, so this is probably an error reading the file)*. https://www.boost.org/development/tests/develop/developer/date_time.html https://www.boost.org/development/tests/develop/developer/dynamic_bitset.ht… Thanks, Jim

2 1

[concept_check] CopyConstructible Concept Does Not Accept Lvalue Reference
by Qu Xing 11 Oct '18

11 Oct '18

Boost version: 1.67.0 Compiler: GCC 7.3.0 Environment: Cygwin on Windows 10 version 1709 In the Boost Concept Check library, CopyConstructible concept requires operator & applicable to the type being checked, and the return value is required to be convertible to pointer to the type. However, pointer to reference is not allowed in C++. This concept check fails to compile if applying to a lvalue reference type. On the other hand, is_copy_constructible<T> type trait class in the Boost Type Traits library and the standard C++ library both give positive result on lvalue reference types. For example, the following code snippet will fail to compile if T is a lvalue reference: #include <type_traits> #include <boost/static_assert.hpp> #include <boost/type_traits/is_copy_constructible.hpp> #include <boost/concept_check.hpp> #include <boost/concept/assert.hpp> template <typename T> void RequireCopyConstructible() { BOOST_STATIC_ASSERT(boost::is_copy_constructible<T>::value); // PASS on lvalue reference BOOST_STATIC_ASSERT(std::is_copy_constructible<T>::value); // PASS on lvalue reference BOOST_CONCEPT_ASSERT((boost::CopyConstructible<T>)); // FAIL on lvalue reference } void TestReference() { RequireCopyConstructible<int&>(); } Diagnosis message is generated as: "error: forming pointer to reference type ‘int&’". I think the operator & applicable requirement should be removed for CopyConstructible concept. Alternatively, adding a template specialization on lvalue reference type for CopyConstructible concept may work as well.

1 0

[config] really, really sticky issue with BOOST_SYMBOL_IMPORT
by Robert Ramey 10 Oct '18

10 Oct '18

For many, many years we've built the Boost serialization library with the macros for BOOST_SYMBOL_IMPORT and BOOST_SYMBOL_EXPORT set according to the instructions included in the boost/config documentation written by John Maddock. These set attributes for creating and using DLLS for windows and (used to) resolve to nothing on other systems. So far so good. At some point things changed for gcc compilers. Now it seems that BOOST_SYMBOL_IMPORT resolves to nothing and BOOST_SYMBOL_EXPORT resolves to : __attribute__ ((visibility("default"))) and BOOST_SYMBOL_IMPORT still resolves to nothing. OK - this has never been a problem. Now we have an extremely subtle issue which appears on linux systems with gcc. It's related to sequence of shared library loading and unloading. It shows up as a bunch of test failures for the test named test_exported_dll. A very astute user has determined that this can be "fixed" by defining BOOST_SYMBOL_IMPORT as __attribute__ ((visibility("default"))) as well. Question. should config/gcc be updated in this way? Also is it possible that this "fix" is just a fluke unrelated to the real source of the problem? Note that this issue predates the recent change to make -visibility=default which has, as one might expect, caused some issues. I believe that this situation is unrelated. Any help appreciated Robert Ramey reference: https://github.com/boostorg/serialization/issues/104#issuecomment-416948110

4 3

Tools to manage multiple repositories effectively?
by James E. King III 09 Oct '18

09 Oct '18

Hello, I am looking for tools that would allow me to create a portal and/or monitor the following properties of boost repositories. I am in the CMT and at least one fix that was in develop never made it into master for the 1.68.0 release, so I want to be able to see, at a glance, information about the boost repositories I care about in one place. There are about 20 repositories I regularly participate in now so a portal to show what I need to worry about would be useful. 1. How far behind is master (with respect to develop)? This would help identify which repositories are behind develop. Useful for ensuring things get into a release. 2. How many open pull requests? 3. How many new pull requests (within the last week)? 4. How many updated pull requests (within the last week)? 5. How many open issues? 6. How many new issues (within the last week)? 7. How many updated issues (within the last week)? "week" could be configured, perhaps month, or "since I last visited". Anybody know of any good tools or perhaps an existing site that can do this for a multi-repository solution? Thanks, Jim

3 2

[system] The new Boost.System is now ready
by Peter Dimov 09 Oct '18

09 Oct '18

The new Boost.System is now complete, on the develop branch: https://www.boost.org/doc/libs/develop/libs/system/ - header-only - even more constexpr than 1.68 - identifier-based category comparison - message() into a caller-supplied buffer - failed() The plan is to merge it to master at some point if no breakage is encountered on develop, so that it can go into the next release.

5 11

Export control classification number for boost
by DEMIAN, Beatrice (SOPRA STERIA GROUP SA) 08 Oct '18

08 Oct '18

Hi, We are using boost in one of our products, and are now in the process of collecting the information needed to export it. Can you tell me what the U.S. Export Control Classification Number (ECCN) for boost is, and whether a license exception may be used for it? Béatrice Demian On behalf of SOPRA STERIA Subcontractor for EYYW6 (AIRBUS France) The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

2 1

[graph_parallel] property_serialize.hpp
by Peter Dimov 06 Oct '18

06 Oct '18

I'm looking at boost/pending/property_serialize.hpp, with the intent of moving it from Graph Parallel to Graph as it's included from a Graph header, and I see this: https://github.com/boostorg/graph_parallel/blob/develop/include/boost/pendi… #ifdef BOOST_GRAPH_USE_MPI namespace boost { namespace mpi { template<> struct is_mpi_datatype<boost::no_property> : mpl::true_ { }; } } // end namespace boost::mpi BOOST_IS_BITWISE_SERIALIZABLE(boost::no_property) BOOST_CLASS_IMPLEMENTATION(boost::no_property,object_serializable) BOOST_CLASS_TRACKING(boost::no_property,track_never) #endif // BOOST_GRAPH_USE_MPI What this does is, when BOOST_GRAPH_MPI is defined, it sets certain serialization properties for boost::no_property (is bitwise serializable, use object level versioning, never track address), but when BOOST_GRAPH_MPI is not defined, it doesn't. That is, the serialization format of boost::no_property changes on the basis of whether BOOST_GRAPH_MPI is defined. (It's the same for boost::property<>, above in the same file.) This does not seem correct to me. I would expect these serialization properties to be applied consistently regardless of whether MPI is used or not. But fixing this could conceivably break existing code that serializes and deserializes non-parallel graphs and relies on a certain format on disk. So... should we fix this or not?

2 2

Cycle between Graph and GraphParallel
by Peter Dimov 06 Oct '18

06 Oct '18

Currently we have a dependency cycle between `graph` and `graph_parallel`. It's not the only one, but it's notable with the fact that both libraries are buildable and we therefore can't ignore it as we can ignore cycles between header-only libraries that at release time become a single directory. In the particular, this impedes efforts to generate CMake config files. Under one scheme I'm currently working on, for instance, Boost.Python can't be installed because it tries to install Graph, which tries to install GraphParallel, which tries to install Graph. The cycle between these two is an interesting one. boost/graph/breadth_first_search.hpp does: #ifdef BOOST_GRAPH_USE_MPI # include <boost/graph/distributed/breadth_first_search.hpp> #endif at its end, and boost/graph/distributed/breadth_first_search.hpp does: #ifndef BOOST_GRAPH_USE_MPI #error "Parallel BGL files should not be included unless <boost/graph/use_mpi.hpp> has been included" #endif #include <boost/graph/breadth_first_search.hpp> at its very start. So these headers include each other. One would naively think that only the parallel header should include the normal one, but one is not well versed in graph library architectures, so one might quite possibly be missing something, or a lot. Comments?

4 4

Formal Review of Proposed Boost.Histogram Library is FINISHED
by Mateusz Loskot 05 Oct '18

05 Oct '18

Dear Boost Community, The formal review of Hans Dembinski's Histogram library has been completed. Here is the quantitative summary of feedback received: * Reviews: 1. Klemens David Morgenstern 2. Jim Pivarski (off-list via e-mail to Hans) 3. Björn Reese 4. Steven Watanabe 5. Alex Hagen-Zanker * Non-review participations: 1. degski 2. Gavin Lambert 3. Seth 4. Mateusz Loskot I believe I've collected the names/numbers right, but please let me know ASAP if you think otherwise. I'd like to thank all the participants for their time and efforts. I'm sure Hans received lots of valuable comments and suggestions. FYI, the discussion threads are still open for new posts. Those won't be taken into consideration towards the review result though. I will do my best to announce the review results next week. Mateusz Review Manager for the proposed Boost.Histogram -- Mateusz Loskot, http://mateusz.loskot.net

1 1

Twenty years and time to retire
by Beman Dawes 04 Oct '18

04 Oct '18

The idea behind Boost was hatched in March, 1998, and the proposal document <https://www.boost.org/users/proposal.pdf> was released May 6, 1998. That makes Boost twenty years old, and makes me twenty years older. It is high time I retire from Boost; I haven't been able to contribute for some time now. Thanks to all of you who made Boost such an overwhelming success in the past and will drive Boost forward into a bright future! --Beman

21 20

Release notes for release 1.69
by Paul A. Bristow 02 Oct '18

02 Oct '18

To avoid forgetting to do it when release time comes, I would like to add some Math and Multiprecision library release notes for the next release 1.69 Is providing a PR for this file that way to do this? ( I speak Quickbook ;-) ) https://github.com/boostorg/website/blob/master/feed/history/boost_1_69_0.q… (but it doesn't exist yet!) Thanks. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

1 0

[histogram] Variance
by Bjorn Reese 02 Oct '18

02 Oct '18

The variance of individual bins can be obtained when using the adaptive_storage (via h.at(i).variance().) I am trying to understand the overhead of this feature. If I interpret the code correctly, there is a space overhead because each counter has to keep track of both the count and the sum of squares. The computational overhead is that the sum of squares has to be calculated for each insertion. Is this correct? If so, is there any way to use the adaptive storage policy without variance? Furthermore, why does variance() return the sum of squares? Should this not be divided by the sample size?

5 8

[asio] Order of asynchronous messages
by Florian Lindner 01 Oct '18

01 Oct '18

Hello, in a distributed application (only local are network) we are experiencing issues which *may* stem from the order of asychronous messages sent over sockets. We create a send buffer: auto buffer = std::make_shared<std::vector<double>>(); and fill it: buffer.push_back(some_data). This buffer is then given to our communication routine request = aSend(*buffer, recipient); to keep the send buffer alive we place it in a class attribute: bufferedRequests.emplace_back(request, buffer); The aSend method from above works like (asio is boost asio, of course) PtrRequest aSend(std::vector<double> const & itemsToSend, int recipient) { PtrRequest request(new SocketRequest); asio::async_write(*_sockets[recipient], asio::buffer(itemsToSend), [request](boost::system::error_code const &, std::size_t) { std::static_pointer_cast<SocketRequest>(request)->complete(); }); return request; } This way, we can check for completion using request->test(), which is set from the callback request->complete(). For checking of completed requests we have a loop, which is called reqularly void checkBufferedRequests(bool blocking) { do { for (auto it = bufferedRequests.begin(); it != bufferedRequests.end();) { if (it->first->test()) it = bufferedRequests.erase(it); else ++it; } if (bufferedRequests.empty()) return; if (blocking) std::this_thread::yield(); // give up our time slice, so communication way work } while (blocking); } which operates on bufferedRequests, that is a list<pair<PtrRequest, PtrBuffer>>. We use that, so that the sending peer is not blocked by a slow receiving peer. The sockets are created like tcp::acceptor acceptor(*_ioService); { tcp::endpoint endpoint(tcp::v4(), _portNumber); acceptor.open(endpoint.protocol()); acceptor.set_option(tcp::acceptor::reuse_address(_reuseAddress)); acceptor.bind(endpoint); acceptor.listen(); } Now we are having problems with mangled data that are unexplainable right now. - Is the order of requests guaranteed to be preserved? I think so, based that asio works on TCP. - What happens if there is another read or write performed on the socket. I think that there is no way to guarantee that this does not interfere with the order of the asynchronous send or queued requests. Last but not least: Do you see any potential problems with that code? Thanks a lot! Florian

3 2

[container][interprocess][intrusive][move] Removing support for old compilers
by Ion Gaztañaga 01 Oct '18

01 Oct '18

Hi, My libraries have supported quite old compilers, starting from Visual 2003 and GCC 3.4 and I'm asking for feedback before I start dropping old compilers. The number of supported plus locally+regression tested versions has increased a lot these years and that's a lot of work with reduced benefits. I run locally for: - From Mingw GCC 3.4 to GCC 8.1, all released minor versions (combining C++03-C++11-C++14-C++14). - From MSVC 7.1 to MSVC 14.1, all released versions (default language standard). I also run boost regression tests for many of those compilers (see "igaztanaga-*" runners in https://www.boost.org/development/tests/master/developer/summary.html) The number of supported and tested compilers is now unmanageable for me as many of those have specific warnings/bugs that I try to fix. So I was thinking about reducing that list a bit dropping support for the oldest ones and replacing them with recent GCC/Clang from WSL (Windows Subsystem for Linux). My first idea is to drop anything older than 10 years, which means that the minimum will be MSVC 9.0 and GCC 4.3 (both released in 2008). I've reviewed some popular long support Linux distributions: -> RHEL 6 uses GCC 4.4. -> SUSE Linux Enterprise Server 11 Service Pack 4 (SP4) uses GCC 4.3 Microsoft no longer supports Visual 2008 (support ended on April 2018) but I can continue compiling and testing it at least for another year. Note that my libraries will continue support for -std=C++03, but I will not find workarounds or fixes for old GCC and MSVC versions. Thoughts, problems, comments? Best, Ion

6 9

[histogram] Formal review
by Bjorn Reese 01 Oct '18

01 Oct '18

Boost.Histogram contains useful and well-designed features, like excess (over/underflow) bins, and axis transforms to name a few. As this is a review, I am going to spent most time below on critical scrutiny. I. DESIGN --------- Iterators are const. This prevents us from bootstrapping the histogram with a prior distribution using STL algorithms like std::fill(), std::generate(), or std::sample(). The adaptive_storage does not work well with STL algorithms, because weight_counter is not an arithmetic type. See the Implementation section below for more detail. I therefore propose that the default storage policy is changed to something without weight_counter. The adaptive_storage has two responsibilities: data compaction and weights. Would it be possible to split this into two separate storage policies? I have no real use for arrival variance. I am not too fond of using operator() for insertion. The code looks like a function call with side-effect. I prefer an explicitly named member function. The axis::ouflow_type is oddly named. I suggest that this is renamed to something like axis::excess_type. II. IMPLEMENTATION ------------------ The implementation is generally of high quality. However, I did encounter the three problem areas listed below. (A) Integration with STL algorithms can be improved. Here are some examples: First, std::distance() does not work on a histogram with array_storage. This means that other STL algorithms, like std::any_of(), fails to compile. I solved this problem by copying the distance_to() function from the axis iterator to the histogram iterator. Second, std::max_element (and brethren) cannot be used on a histogram. Consider the following example: auto element = std::max_element(h.begin(), h.end()); Compilation fails for adaptive_storage because weight_counter has no less-than operator. Furthermore, compilation fails for array_storage because iterator_over<H>::operator= fails. It attempts to re-assign a reference, but accidentally triggers a copy-constructor instead. Letting the iterator store a pointer instead of a reference solves the problem. Apropos, iterator_over<H>::operator= does not return *this. Consider adding the -Werror=return-type compiler flag and a unit-test to that calls this operator. Third, std::inner_product fails to compile for adaptive_storage because weight_counter does not have a binary operator*. The inner product of two histograms is useful for calculating the cosine similarity, which can be used to compare two distributions. std::inner_product works for array_storage though. (B) Indexing and size use different types (int versus std::size_t.) I assume that this is because of the underflow bin, which is indexed by -1. I am not certain whether or not this is a real problem, but it does cause some oddities when stressed to the limit. For example, if we need a histogram that counts each unsigned int, then we get an "lower < upper" exception during construction: using range_type = unsigned int; auto h = make_static_histogram_with( array_storage<int>(), axis::integer<>(0, std::numeric_limits<range_type>::max())); It works if we reduce the end by 2, but then we are not collecting all values (unless we shift the range left by 1 and misuse the excess bins for the two missing values.) A possible solution could be to replace the -1 and N excess indices with an "enum struct excess { lower, upper }" and let operator[] et al use overloading on this enum. (C) Sometimes the compilation errors are nonsensical. For example: // Forgot to use make_static_histogram_with() auto h = make_static_histogram(array_storage<int>, axis::regular<>(10, 0, 1)); triggers an incomprehensible static_assert plus an error about a missing .shape() function. III. DOCUMENTATION ------------------ User guide is clear and pedagogical. I would like to see more examples that uses STL algorithms, such as calculating the CDF using std::partial_sum(), or calculating the cosine similarity of two histograms using std::inner_product(). Most examples use std::cout plus a comment to document the results of operations. Consider using assert() instead. Consider using a tabular layout similar to that of the C++ standard (or cppreference.com for that matter) on the Concepts page. Reference documentation is rather meager and shows implementation details. The documentation contains both a "Reference" and a "References" chapter which are completely different. Consider renaming the latter to something like "External references" , "Literature references", or "Bibliography". IV. MISC -------- I have spent around 15 hours on the review, mainly writing small examples that uses STL algorithms on Boost.Histogram. I am well-versed in the topic. I work with statistical distributions for real-time analysis of data, although I mainly dabble around in one dimension. I have written a library for online/streaming statistical algorithms. V. VERDICT ---------- While Boost.Histogram is a small niche library, it has a wide range of practical applications to warrant the inclusion into Boost. Boost.Histogram should be ACCEPTED into Boost, provided: 1. Reference documentation is finalized. I furthermore strongly recommend that the default storage policy is changed to something without weight_counter because of the various problems with STL algorithms. This recommendation is not a prerequisite for acceptance.

2 3

Median in Boost.Accumulators
by Lakshay Garg 30 Sep '18

30 Sep '18

Hello Boost Some time ago, I needed to compute the exact median for a stream of elements and after using Boost.Accumulators, realized that it only provides an approximation of the median and not the exact number. I rolled up my custom implementation of the algorithm and used it for my project. I wanted to check if people on this list might be interested in such an implementation for Boost.Accumulators in which case I can try to adapt my implementation and send a PR. Performance characteristics: For a stream of n numbers, the memory required is O(n). Median can be queried at any point of time in O(1) and adding all the elements costs O(nlog(n)) Lakshay

3 5

Will boost support DTLS / UDP?
by jupiter 29 Sep '18

29 Sep '18

It seems to me that Boost does not support DTLS so far, any plan and time line for boost to support DTLS?

2 1

CMake in Boost
by Robert Ramey 29 Sep '18

29 Sep '18

Many have expressed the desire that Boost support CMake. The Boost Board of Directors has emitted some sort of resolution to this effect - it's been a year. I would like to see progress in this direction. To this end I propose the following: a) Boost announce that a review of proposals to incorporate CMake into boost will be held in January 2019. This will follow customary Boost practices. b) Those who are willing and able to submit code/documentation and whatever else in necessary should do so before this date. I would anticipate at least two such submissions. As is the case with other reviews, I would not exist such submissions to be totally complete. But I would expect that they include enough for reviewers to test and practice with the proposed system. c) Prior to this discussions can be held on the list regarding the scope of such an effort. The review manager will distill these discussions to a statement of scope. This will be posted around 30 October 2018. I nominate myself (Robert Ramey) as review manager in this instance. Why would I do this? a) Boost needs this b) I've never been a review manager c) I'm a masochistic idiot. Robert Ramey

4 8