July 2021 - Boost - lists.preview.boost.org

Boost.Text is looking for a (mini-)review manager
by Zach Laine 07 Dec '22

07 Dec '22

I've made all the recommended changes to Boost.Text that came up in the review. Glen, the previous review manager, recommended a mini review of Boost.Text once I'd made those changes. If you'd like to manage the mini-review, please let me know. For everyone, including potential reviewers and review managers, here are the major changes: * All the specific review feedback issues have been addressed. * The string layer is now gone. * The text layer got a major re-work. It is now a set of template-based adaptors (basic_text<>, vs. a text typedef. etc.), which lets everyone get what they want. You can change the underlying storage type (including whatever allocator you prefer), select UTF-8 or UTF-16, and change the normalization form. Glen recommended I drop this layer, but the library is way less useful without this stuff, and these changes address all the concerns raised about the text layer in the review. The updated docs can be found here: https://tzlaine.github.io/text/doc/html/index.html Oh yeah, and I added concept constraints to the whole library when you build in C++20 mode. Zach

17 46

[review][JSON] Review of JSON starts today: Sept 14 - Sept 23
by Pranam Lashkari 09 Aug '22

09 Aug '22

Boost formal review of Vinnie Falco and Krystian Stasiowski's library JSON starts today and will run for 10 days ending on 23 Sept 2020. Both of these authors have already developed a couple of libraries which are accepted in Boost(boost beast and Static String) This library focuses on a common and popular use-case for JSON. It provides a container to hold parsed and serialised JSON types. It provides more flexibility and better benchmark performance than its competitors. JSON highlights the following features in the documentation: - Fast compilation - Require only C++11 - Fast streaming parser and serializer - Easy and safe API with allocator support - Constant-time key lookup for objects - Options to allow non-standard JSON - Compile without Boost, define BOOST_JSON_STANDALONE - Optional header-only, without linking to a library (a point I would like to add in highlight: it has cool Jason logo 😝) To quickly understand and get the flavour of the library take a look at "Quick Look" <http://master.json.cpp.al/json/usage/quick_look.html> You can find the source code to be reviewed here: <https://github.com/CPPAlliance/json/tree/master> You can find the latest documentation here: <http://master.json.cpp.al/> Benchmarks are also given in the document which can be found here: <http://master.json.cpp.al/json/benchmarks.html> Some people have also given the early reviews, the thread can be found here: <https://lists.boost.org/Archives/boost/2020/09/249745.php> Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including JSON as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: <http://www.boost.org/community/reviews.html> Thank you for your effort in the Boost community. -- Thank you, Pranam Lashkari, https://lpranam.github.io/

21 73

[container] Contributing 'stationary_vector' to Boost
by Mehrdad Niknami 13 Jun '22

13 Jun '22

Hi all, Happy new year! New mailing list member here. I've developed an STL-style stationary_vector class that retains elements in-place when growing. Very briefly, it is effectively a piecewise-contiguous vector, with the following advantages over vector: - Appending has O(1) overhead in the *worst* case (e.g., push_back() does not move elements) - Insertion and random-access can be done in parallel, as prior iterators & references remain valid This has a variety of benefits, including better UX (no "hiccups" due to reallocations), and the ability to simplify parallel processing of streaming data. It occurred to me the larger C++ community might find this useful. I was wondering if there would be interest in incorporating it into Boost.Container, and if so, what steps I could take to make that happen? I'm of course happy to discuss the design etc. with anyone who might be interested. Summary: https://github.com/mehrdadn/libvital/blob/master/doc/vital/container/statio… Implementation: https://github.com/mehrdadn/libvital/blob/master/include/vital/container/st… Thank you, Mehrdad

7 19

Adding my sorting algorithm, ska_sort, to boost, attempt 2
by Malte Skarupke 24 Nov '21

24 Nov '21

Hi everyone, I started a discussion about this in October, but at the time the maintainer of the sort library was busy, then I was busy, so now it's January... I wrote a generalized version of radix sort a couple years ago and gave a talk about it here: https://www.youtube.com/watch?v=zqs87a_7zxw I would like to get a new version of that sorting algorithm into boost. It's faster than what I showed several years ago. It's also even more general and has a new interface that should be easier to extend. I uploaded the code here: https://github.com/skarupke/sort/tree/master The documentation is also already updated with new benchmark results. Let me know what's required to get this into boost. Would you like this in the form of a pull request? One of the big things that probably needs review is the interface, since radix sorting works differently than comparison based sorting. For most normal uses you just need to provide a sort key, but more complicated cases can get more complicated. I tried very hard to make everything easy, but I'd also be curious if others can come up with better ways of doing the interface. Thanks, Malte -- Malte Skarupke malteskarupke(a)fastmail.fm

8 10

I would like to add boost::algorithm::is_clamped, how to proceed?
by Ivan Matek 13 Aug '21

13 Aug '21

Hi, I would like to add is_clamped (that tests if the value is clamped, similar how we have std::is_sorted, std::sort). What would be the proper procedure? I have never committed to boost, so I have no access to any repository, no "contacts", so I have no idea if small proposals like this require just approval from owner or it needs broader discussion(for example in some cases it would be nice fix for missing chain comparison <https://www.geeksforgeeks.org/chaining-comparison-operators-python/> in core language, but then is_clamped name is not that nice, is_between might be nicer,...). Also I am not sure if this is the best place to ask for directions and do discussions, if you have some slack channel or forum you prefer please let me know. There was a proposal <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1440r0.html>for std::, but it is not in C++20. I have no relation to that proposal. regards, Ivan

3 8

Regexp performance guarantees
by Phil Endecott 30 Jul '21

30 Jul '21

Dear Experts, I recently wanted to add some input-sanitising code to a C++ web application, and as I had some existing Javascript code I decided to port its regex-based input checking to the C++ code. This didn't go as well as I had expected! Here's an example of the sort of thing I have: if (!regexp_match(s, regex("[A-Za-z0-9-_/]{1,8192}"))) throw MalformedInput(); The Javascript equivalent seems to be fine. In C++, with libstdc++'s regex implementation, it seems to take about 2 seconds to run. Boost.Regex didn't like the '-' after the '9' but when I fixed that the execution time became negligible. Boost.Xpressive seems also to be fast. On investigation it seems that this is due to there being two different algorithms, one of which (DFA) is linear in the string size but exponential in the pattern size (which in this case seems to mean exponential in the max repeat value of 8192), and the other (backtracking) is linear in the pattern size but exponential in the string size. It seems that the standard deliberately doesn't specify complexity guarantees for std::regex, leaving the choice of algorithm to the implementation. I find this a bit surprising. It's true that both algorithms have their strengths, but not knowing which you are going to get is the worst of both worlds - you would have to assume that it will be exponential in both pattern and string sizes in portable code! (Imagine a container that doesn't disclose whether it has vector or list complexity!) So I'm wondering if it would be useful for regex libraries to somehow be explicit about which algorithm they are and what the complexity is. Compare, for example, with the text search algorithms (Boyer-Moore etc) which indicate the algorithm in their names. Could we have regex_dfa / regex_backtracking, or something? Now having said that, I think that what I really need for my application is something that is worst-case linear in both the pattern size and the input string. I'm not sure if the apparently-fast Boost.Regex algorithm has a worst-case input that is slow. ("Regular Expression Denial Of Service"). It's clear that my example can be written without a regex as a simple linear loop, and maybe some regex libraries have heuristics that do that. Thoughts anyone? Regards, Phil.

8 13

[release] 1.77.0 post-beta merges
by Marshall Clow 30 Jul '21

30 Jul '21

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/wiki/wiki/Releases%3A-Beta-Merge-Policy> Reminder: The master branch closes for the release on Wednesday, August 4th. Full calendar here: https://www.boost.org/development/ <https://www.boost.org/development/> — Marshall P.S Doc changes and test changes do NOT require release manager approval to be merged.

5 13

Different Lib/CMake Layout between Pre-Build-Binaries and Build from source
by Dennis Luehring 26 Jul '21

26 Jul '21

target_link_libaries(... Boost::boost) seems not to work if the stagedir/<lib> folder is missing but the pre-build binaries missing this folder https://sourceforge.net/projects/boost/files/boost-binaries/1.75.0/ https://sourceforge.net/projects/boost/files/boost-binaries/1.75.0/boost_1_… boost_1_75_0 <boost> ... bootstrap.bat bootstrap.sh <lib64-msvc-14.1> <cmake> *.lib if i build 1.75.0 from source with b2 --toolset=msvc-14.1 --stagedir=./lib64-msvc-14.1 address-model=64 architecture=x86 link=static threading=multi i've get this hierachy c:\Boost\boost_1_75_0 <boost> ... bootstrap.bat bootstrap.sh ... <lib64-msvc-14.1> <-- stagedir <lib> <cmake> *.lib what is the very same hierarchy with Qt6 cmake-configs (so its seems to be "more" standard) C:\Qt\6.1.2 <msvc2017_64> <-- aka "stagedir" <lib> <cmake> Qt6*.lib why does the pre build binary package got a different hierarchy?

1 0

[bimap][PR RFC] Add std::initializer_list constructor
by Hu Jialun 23 Jul '21

23 Jul '21

C++11 allows list initialization for classes. STL map has been added a constructor with the signature map(initializer_list<value_type> il, const allocator_type& alloc = allocator_type()); Added a similar constructor to bimap, allowing for initialization in the form of initializer list, such as boost::bimap<double, long> tdn { {114.514, 1919}, {891.931, 810} }; --- Seems that the pull request is not being seen for a while... Could someone please take a quick look at it and possibly give some directions? :) https://github.com/boostorg/bimap/pull/31 include/boost/bimap/bimap.hpp | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/include/boost/bimap/bimap.hpp b/include/boost/bimap/bimap.hpp index 5fe7a3f..a3603e5 100644 --- a/include/boost/bimap/bimap.hpp +++ b/include/boost/bimap/bimap.hpp @@ -265,6 +265,29 @@ class bimap {} + #ifndef BOOST_NO_CXX11_HDR_INITIALIZER_LIST + bimap(std::initializer_list<BOOST_DEDUCED_TYPENAME base_::core_type::value_type> init, + const allocator_type& al = allocator_type()) : + + base_::relation_set( + ::boost::multi_index::get< + BOOST_DEDUCED_TYPENAME base_::logic_relation_set_tag>(core) + ), + + core(init,ctor_args_list(),al), + + left ( + ::boost::multi_index::get< + BOOST_DEDUCED_TYPENAME base_::logic_left_tag>(core) + ), + right ( + ::boost::multi_index::get< + BOOST_DEDUCED_TYPENAME base_::logic_right_tag>(core) + ) + + {} + #endif + bimap(const bimap& x) : base_::relation_set(

1 0

CMake: using boosts own package finding stuff, howto?
by Dennis Luehring 19 Jul '21

19 Jul '21

in short: CMake does need to change (i'll need to wait for updates) to support newer released boost versions i've heard that Boost supports cmake now directly but i don't get the direct cmake support of boost working with my CMakeLists.txt i know that CMake supports 1.75 in the lastest releases directly but 1.76 and 1.77 are still not on the list and i don't want to wait for CMake release to test new features/betas etc. my system: Ubuntu 21.04/x64, CMake 3.19.4/3.21.0, GCC 10.x Boost 1.75 (want to upgrade to 1.76 soon) my boost build: mkdir ~/dev/3rdparty-liux-gcc cd ~/dev/3rdparty-linux-gcc wget https://dl.bintray.com/boostorg/release/1.75.0/source/boost_1_75_0.tar.bz2 tar -xf boost_1_75_0.tar.bz2 ln -s boost_1_75_0 ./boost cd boost_1_75_0 ./bootstrap.sh ./b2 --toolset=gcc cxxflags=-fPIC --build-dir=./_build address-model=64 architecture=x86 link=static threading=multi --with-graph --with-nowide --with-test --width-config --with-system --with-filesystem --stagedir=./_x64 ln -s _x64/lib lib my simple test hierarchy: boost_using_cmake_tests boost_using_cmake_tests\_build boost_using_cmake_tests\boost_using_cmake boost_using_cmake_tests\boost_using_cmake\CMakeLists.txt cmake_minimum_required (VERSION 3.16) set(Boost_NO_BOOST_CMAKE TRUE) set(Boost_NO_SYSTEM_PATHS TRUE) project (using_boost_with_cmake) set( MY_THIRD_PARTY_LIBS "~/dev/3rdparty-linux-gcc" ) set( BOOST_ROOT ${MY_THIRD_PARTY_LIBS}/boost ) set( BOOST_INCLUDEDIR ${BOOST_ROOT}/boost) set( BOOST_LIBRARYDIR ${BOOST_ROOT}/lib) find_package(Boost REQUIRED COMPONENTS unit_test_framework filesystem system) cmake run: using 3.19.4 cmake without 1.75 support ~/dev/boost_using_cmake/_build$ ../../cmake-3.19.4-linux-x86_64/bin/cmake ../boost_using_cmake/ -- The C compiler identification is GNU 10.3.0 -- The CXX compiler identification is GNU 10.3.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done CMake Warning at /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1204 (message): New Boost version may have incorrect or missing dependencies and imported targets Call Stack (most recent call first): /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1326 (_Boost_COMPONENT_DEPENDENCIES) /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1935 (_Boost_MISSING_DEPENDENCIES) CMakeLists.txt:14 (find_package) CMake Warning at /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1204 (message): New Boost version may have incorrect or missing dependencies and imported targets Call Stack (most recent call first): /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1326 (_Boost_COMPONENT_DEPENDENCIES) /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1935 (_Boost_MISSING_DEPENDENCIES) CMakeLists.txt:14 (find_package) CMake Warning at /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1204 (message): New Boost version may have incorrect or missing dependencies and imported targets Call Stack (most recent call first): /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1326 (_Boost_COMPONENT_DEPENDENCIES) /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1935 (_Boost_MISSING_DEPENDENCIES) CMakeLists.txt:14 (find_package) -- Found Boost: /home/linux/dev/3rdparty-linux-gcc/boost (found version "1.75.0") found components: unit_test_framework filesystem system -- Configuring done -- Generating done -- Build files have been written to: /home/linux/dev/boost_using_cmake_tests/_build it works but cmake 3.19.4 is missing direct support for 1.75 so its some way "unsupported", cmake does not detect the correct lib names automaticly, only some styles are working etc. i've talked about the problem on the cmake forum and the answer was https://discourse.cmake.org/t/fail-to-use-self-build-boost-1-75-under-ubunt… Brad King: "...However, Boost upstream now provides a proper CMake package file BoostConfig.cmake which should work for using Boost in any layout..." 1.75 is now directly supported by cmake - but now i want to use 1.76 and the problem re-occures i've tried serveral things to force cmake to use the boost own package findings stuff without any success i hope its possible to use 1.75 and 1.76 in the future without always wait for cmake to support it directly any hints what changes are needed with my CMakeLists.txt to support boost own cmake package finding (and get rid of these problems)?

4 17