June 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

The deadline for Major changes for Boost 1.77.0 is TODAY!
by Marshall Clow 04 Jul '21

04 Jul '21

See https://www.boost.org/development/index.html <https://www.boost.org/development/index.html> for the full calendar — The Release Managers

4 6

Poor performance on windows with logging sinks::file_collector when two file logs use same directory. Thoughts?
by Nicholas Neumann 24 Jun '21

24 Jun '21

I've got two different rotating file logs that point to the same directory (with different file name patterns). Is this in general just a bad idea? They end up sharing the same file_collector, which seems wrong, so perhaps that is a clue that I shouldn't have my logs set up like this. In production I've got a service that compresses, archives, and manages the size of the logs. But in dev, I don't, so the number of files in the directory slowly grew. But the startup time for my program grew much faster. On windows the scan_for_files function in the collector has a loop that is O(mn), where m is the number of files in the directory, and n is the number that matched in previous calls to the scan_for_files function This means the scan_for_files for the first rotating file log in the directory has no issue (n is 0), but the second can be problematic. It iterates over the files in the directory and for each file in the directory, it calls filesystem::equivalent on all of the matches from previous scan_for_files calls. On windows, filesystem::equivalent is particularly heavy, opening handles to both files. Thoughts? Is the two file logs getting the same collector the real issue? Or is it my pointing two file logs to the same directory? I see some ways to mitigate the slowdown in scan_for_files - e.g., filesystem::equivalent could be called after all of the method/match_pattern check, but the two file logs sharing the same collector feels like the real issue.

3 3

The deadline for new libraries and breaking changes in Boost 1.77.0 is this Wednesday, June 23
by Marshall Clow 21 Jun '21

21 Jun '21

See https://www.boost.org/development/index.html <https://www.boost.org/development/index.html> for the full calendar — The Release Managers

1 0

Re: [boost] What has become of John Maddock's implementation of the Remez algorithm for Chebychev approximation?
by Bjorn Reese 18 Jun '21

18 Jun '21

On 6/15/21 11:48 PM, Joachim Wuttke via Boost wrote: > Until v1.53, Boost Math had doc pages [1,2] on the Remez algorithm. > This algorithm [3] computes the coefficents of the Chebyshev polynomial > that approximates a given function. Page [2] refers to actual code In addition to John's reply, I wanted to add that Boost.Math has direct support for Chebyshev polynomials now: https://www.boost.org/doc/libs/release/libs/math/doc/html/math_toolkit/sf_p…

4 5

What has become of John Maddock's implementation of the Remez algorithm for Chebychev approximation?
by Joachim Wuttke 16 Jun '21

16 Jun '21

Until v1.53, Boost Math had doc pages [1,2] on the Remez algorithm. This algorithm [3] computes the coefficents of the Chebyshev polynomial that approximates a given function. Page [2] refers to actual code in directory libs/math/minimax. This code can still be found on GitHub [4], but maintenance status and dependences are unclear. Anybody around who knows anything about this code? Kind regards, Joachim [1] https://www.boost.org/doc/libs/1_53_0/libs/math/doc/sf_and_dist/html/math_t… [2] https://www.boost.org/doc/libs/1_53_0/libs/math/doc/sf_and_dist/html/math_t… [3] https://en.wikipedia.org/wiki/Remez_algorithm [4] https://github.com/boostorg/math/tree/develop/tools/minimax -- Dr. Joachim Wuttke group leader Scientific Computing Forschungszentrum Jülich GmbH Jülich Centre for Neutron Science at MLZ https://computing.mlz-garching.de https://jugit.fz-juelich.de/mlz

2 1

Using Boost.Test header-only from CMake
by Peter Dimov 15 Jun '21

15 Jun '21

Some libraries (I encountered this when porting the tests of Signals2) use Boost.Test in header-only mode, by including <boost/test/included/unit_test.hpp> without linking to anything. This worked in the "legacy" structure where all headers are always available, but doesn't work under CMake where you have to link to header-only libraries in order to get the proper include path. Should we make an attempt to support this use by declaring a special header-only target in Boost.Test (e.g. Boost::included_unit_test), or is that a waste of time? One can as well link to the proper Boost::unit_test_framework (and then even use it header-only, although there's not much point in doing so.) I'm inclined towards "waste of time".

10 34

Re: [boost] boost-json apt-get packge
by Vollaro, John 14 Jun '21

14 Jun '21

Date: Fri, 11 Jun 2021 01:42:18 +0300 From: "Peter Dimov" <pdimov(a)gmail.com> To: <boost(a)lists.boost.org> Subject: Re: [boost] boost-json apt-get packge Message-ID: <05f001d75e49$decba2f0$9c62e8d0$(a)gmail.com> Content-Type: text/plain; charset="utf-8" Vollaro, John wrote: > Is their a apt package that includes boost-json? For what distro? debian > This apt packages did not include boost-json > > apt-get install libboost1.76-all-dev Should be libboost1.76-json-dev. Could not find this package. This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.

2 1

CMake minimum version to support
by Peter Dimov 11 Jun '21

11 Jun '21

I suppose the time has come to have the discussion on the minimum CMake version we will support for building Boost. Currently that's set to 3.5, which kind of works, but is fairly inconvenient. The interesting options are - CMake 3.8: required for use of the compile features cxx_std_11, cxx_std_14, cxx_std_17, etc. Also allows source_group(TREE, which is used by Json and PropertyTree. - CMake 3.9: required by Nowide, I'm not sure why. Also, required for FindMPI to define an imported target. Building Boost.MPI is optional though. - CMake 3.13: required for Boost installation support. - CMake 3.14: required for FindPython to be modern enough to make building Boost.Python reasonably easy. (Building Boost.Python is optional, though.) There are also less important nice-to-have things such as - CMake 3.10: adds include_guard() - CMake 3.12: adds CONFIGURE_DEPENDS to file(GLOB - CMake 3.15: adds VERBOSE/DEBUG to message( Opinions?

15 40

boost-json apt-get packge
by Vollaro, John 10 Jun '21

10 Jun '21

Is their a apt package that includes boost-json? This apt packages did not include boost-json apt-get install libboost1.76-all-dev ____________________________ John Vollaro 185 Asylum St 6th Floor, Hartford, CT 06103 O: 860-702-8563 | M: 860-919-9443 | john.vollaro(a)optum.com<mailto:john.vollaro@optum.com> This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.

2 1

Re: [boost] Using Boost.Test header-only from CMake
by Glen Fernandes 10 Jun '21

10 Jun '21

On Sun, Jun 6, 2021 at 9:51 PM Peter Dimov wrote: > For completeness, the libraries using the deprecated boost/test/minimal.hpp are: > > foreach > graph > graph_parallel > iterator > logic > numeric/conversion > numeric/interval > property_map > tokenizer > units > yap > > These need to migrate to either LWT or the non-deprecated Boost.Test. I've migrated all of the above to LWT. Graph is still a PR that needs to be merged. Glen

1 0

Fwd: Interested in contribution to this organisation.
by Chandrakant Jena 16 09 Jun '21

09 Jun '21

---------- Forwarded message --------- From: Chandrakant Jena 16 <chandrakant.barcelona(a)gmail.com> Date: Wed, Jun 9, 2021 at 9:47 AM Subject: Interested in contribution to this organisation. To: <boost(a)lists.boost.org> hello devs, I am chandrakant jena currently studying computer science in utkal university, bhubaneshwar,Odisha. my current interest is c++ and I found this organisation really interesting and suitable for me. I want to know how can I get started? here are some of my profile links: linked in: https://www.linkedin.com/in/chandrakant-jena-5aab131a7/ github profile: https://github.com/chandrakant100

2 1

[cmake] Problem with dependencies for configure checks
by Andrey Semashev 08 Jun '21

08 Jun '21

Hi, I've been having this problem with CMake in Boost.Filesystem, where I need to have the Boost::library targets available before Boost::filesystem target is defined. This is needed in order to perform configuration checks that will affect how Boost::filesystem will be defined. For example, see the check_cxx_source_compiles calls: https://github.com/boostorg/filesystem/blob/af6ac28b5785820b93a2af7dd6e9b80… For the check_cxx_source_compiles calls, I would have liked to add targets like Boost::config and Boost::winapi to CMAKE_REQUIRED_LIBRARIES so that the checks are compiled with include directories of those dependencies added in the command line. This doesn't work because these targets may not be defined at the point when the configuration checks are performed. My current workaround, as you can see, is to add the Boost root to CMAKE_REQUIRED_INCLUDES, where the boost directory with the common headers tree is located. However, this will not work if we're going to make that directory optional or remove it. Also, you can see that I'm reusing checks implemented in Boost.Config, for which I also had to hard code its relative location from Boost.Filesystem. If we're going to allow different libraries located in separate directory trees, this will also break. My question is, can this be fixed and how? I was wondering if it is possible to make the target generation two-stage, where the first stage identifies library locations, including directories with their headers, and the second stage would define build targets. This way all library directories would be available to the second stage. Although I can already see the problem with second order dependencies with this approach...

5 34

CMake progress report
by Peter Dimov 06 Jun '21

06 Jun '21

At the moment, we're down to the following libraries missing CMake support on develop: asio locale log numeric/odeint numeric/ublas parameter_python python sync I've asked Chris how we can proceed with adding a CMakeLists.txt file to ASIO so that we can unblock Log (and Beast.) In addition, the following libraries are currently disabled as having incompatible CMakeLists.txt files in their root directories: beast callable_traits compute gil hana hof safe_numerics static_string stl_interfaces yap I'm working on documenting the CMake support infrastructure, but I'm not done yet.

2 3

Best way to hash_combine a bool?
by John Maddock 05 Jun '21

05 Jun '21

What's the best way to combine a hash value with a bool? Specifically, if you're generating a hash value for a class which has a one member a bool. Normally I would just boost::hash_combine all the class members together, but doing that with a bool member leads to: 1>d:\data\boost\boost\boost\multiprecision\detail\hash.hpp(20,88): warning C4805: '^': unsafe mix of type 'T' and type 'size_t' in operation 1> with 1> [ 1> T=bool 1> ] Followed by a long instantiation backtrace (this is from Boost.Multiprecision). Since there's only one bool in this class, I could just apply a unary ~ to the value when the bool is true, but obviously that wouldn't work for classes with multiple bool's. Should we modify hash_combine for this use case? Cheers, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 2

license violations
by tom.beacon 03 Jun '21

03 Jun '21

To whom should possible license violations be reported? Sent with [ProtonMail](https://protonmail.com) Secure Email.

1 0

Reviewing my first file transfer using Asio
by Farbod Ahmadian 01 Jun '21

01 Jun '21

Hi everyone, I was learning Boost.Asio recently and to learn by doing a project, I decided to write a simple file transfer. So I wrote an *Async TCP Server* and a *Sync TCP Client; *you can use a client to send any kind of file to the server. This is how it works: 1) Clients connect to the server. 2) Clients send the file name to the server. 3) If everything is okay, the server will return an "OK" to that client and wait for that client to send the file. 4) If the client received "OK", it'll send the file. 5) If everything goes well, the file is received by server and the connection will be closed. I will attach the source codes in this email. So here are my questions: 1) Would you mind please review my code and say the problems? I'm a newbie in Asio ;) 2) How to make my client and server talk with a special protocol? Let's say HTTP. (If a socket server understands HTTP, will it be a web server? something like Nginx and Apache.) 3) What is the next step? How can I improve this? What should I learn/do next? Anything is kindly appreciated :) With best regards, Farbod

2 2