- Boost - lists.boost.org

Discuss: Editorial Control Over Repositories and Libraries
by Vinnie Falco 21 Aug '21

21 Aug '21

So, I have a whole bunch of new libraries marching towards completion and proposal for Boost. I have Boost.URL and Boost.HTTP-Proto in the works, and there is some code that I want to share between the two. Files like these: Algorithms to assist processing RFC7230 compliant input: <https://github.com/vinniefalco/http_proto/blob/9d3144c60b3426509b45cc63dbb3…> <https://github.com/vinniefalco/http_proto/blob/9d3144c60b3426509b45cc63dbb3…> <https://github.com/vinniefalco/http_proto/blob/9d3144c60b3426509b45cc63dbb3…> These are public interfaces, and they are equally useful to both URL and HTTP-Proto. They will also be likely useful to processing websocket handshake field values. It would be nice if I could put them in a separate repository with its own tests, documentation, and CI. But I don't know that this is enough meat on the bone so to speak, to justify as a complete new Boost library offering. When Boost.URL returns a std:::string the user has the option of providing a custom allocator. The library comes with this interface which uses a local stack buffer: <https://github.com/CPPAlliance/url/blob/111b83cc4726f3144194dc3546e096d60ac…> This can be used to avoid dynamic allocation when, for example - you want to apply decoding to a URL-encoded input, which happens often. Boost.HTTP-Proto would benefit from this class as well. Again we have the case of a common component that belongs in a separate repository. But this allocator isn't really related to the BNF-processing utilities mentioned above. So where would it go? As I use MSVC exclusively for regular development, I have put together a small unit test facility which is tailored to my workflow: <https://github.com/vinniefalco/http_proto/blob/9d3144c60b3426509b45cc63dbb3…> This has the flavor of Boost lightweight test, but also: * Redirects output to the Visual Studio IDE if a debugger is attached * Supports the model where one executable is built which holds all the tests * A command-line argument facility to specify individual test suites to run I use this in all of my Boost libraries and to-be-proposed libraries. I wouldn't say that it is user-facing. Currently I put a copy of the file in each library but I have made some changes and it would be better if I could put it in a shared place in the Boost tree. But it isn't public so it shouldn't be grouped with the BNF and the allocator stuff above. I am working on new libraries which do ASIO networking, and they use this handy mocking class which is used for testing stream algorithms: <https://github.com/boostorg/beast/blob/21cd552399aa8167ed53c21a74f3711c2c31…> This is a public interface, which users deploy for their own tests (for example the windows-tls project uses it). Again the case where I want to use it in tests for my own new libraries but without making a copy of the source. In other words in its own shared place. It does require ASIO, so I'm not sure it should be grouped with the rest of the stuff above. Now going back to these new libraries, I have Boost.HTTP-Proto which is a brand new library that speaks HTTP/1 but you have to bring your own networking. It is purely a low-level protocol library, but with a scope expanded from Beast to support more useful things that users need. Since networking is obviously needed I am developing the companion library Boost.HTTP-IO in parallel which uses ASIO to drive the protocol library. They use separate repositories and thus the protocol library is physically isolated, has its own tests, CI, and documentation, and so forth. There is a cosmetic issue where users have to write boost::http_proto::request if they want to declare a request container but then they have to write boost::http_io::write if they want to send the request over a socket (note the different namespaces). This is kind of annoying, and becomes even more annoying when you have to remember which namespace the error constant is located in: http_proto::error::end_of_message or http_io::error::end_of_file. One possibility is for these libraries to use the same namespace: boost::http. Or boost::http_proto. But this breaks the rule of one-repository, one-unique-namespace. Once these libraries are done I will at some point want to write Boost.Websocket-Proto and Boost.Websocket-IO which are similar to their HTTP counterparts (*). And then we will have twice the number of namespaces and error constant enums: boost::http_proto boost::http_io boost::websocket_proto boost::websocket_io and boost::urls These all have their own error enums called "error". If we create a separate repository for common code that all 5 of these libraries use, then that's a sixth namespace also with error code. Okay so that's the stuff that I've been pondering as I write this new code, are any of these real problems? What can I do about it? I'm interested in your thoughts. * The purpose of writing these new, seemingly duplicative libraries is to build on the experience of Beast to smooth out the discovered rough edges and provide a superior interface and implementation. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

1 0

Any reason to not add asynchronous sink version of boost::log::add_file_log?
by Nicholas Neumann 19 Aug '21

19 Aug '21

The boost::log::add_file_log function in <boost/log/utility/setup/file.hpp> is a nice function for setting up a file sink. I had been using it and needed to switch from a synchronous frontend to an asynchronous one. But the sink returned is synchronous. Is there any reason to not add a version of the function which creates and returns an asynchronous frontend? Perhaps called something like add_async_file_log?

1 0

Master Branch now open for merging
by Marshall Clow 15 Aug '21

15 Aug '21

No restrictions; the release calendar is up to date. https://boost.org/development <https://boost.org/development> Next milestone: 20-Oct Boost 1.78.0 closed for new libraries and breaking changes — Marshall

1 0

Want to contribute
by Neeraj Khatri 15 Aug '21

15 Aug '21

Can I get help from the organization that how shall I start my contribution in this organization. Thank You ................ .........

1 0

[Boost.Units] Runtime Unit Conversions
by C.D. Clark 15 Aug '21

15 Aug '21

Good day, I have been using Boost.Units for several years now, and it is a great library. I find it difficult to write code without it anymore. However, it does not do runtime unit conversions, so I write a little library that does https://github.com/CD3/UnitConvert It uses Boost.Spirit to parse strings into quantities, and was an excuse for me to learn about spirit. It supports create a boost::units::quantity<T> object from the runtime quantity. Would anybody be interested in adding this type of capability to the boost unit library? I am not a computer scientists, so I don't believe I would be able to propose something up to the boost standard on my own. cdclark -- C.D. Clark III, PhD Associate Professor Department of Physics Fort Hays State University 600 Park Street Hays, KS 67601 Ph: 785.628.4502

2 1

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

is_constant_evaluated
by Robert Ramey 11 Aug '21

11 Aug '21

Any chance of seeing a feature macro for HAS_IS_CONSTANT_EVALUATED appearing in Boost.Config any time soon? Robert Ramey

8 20

[release] Boost 1.77.0 Release Candidate 1
by Marshall Clow 06 Aug '21

06 Aug '21

The first release candidates for the 1.77.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.77.0/source/> The SHA256 checksums are as follows: fc9f85fc030e233142908241af7a846e60630aa7388de9a5fafb1f3a26840854 boost_1_77_0_rc1.tar.bz2 f2dd9722b21450daf5ce8ef82c2d99c7ec304f913ee6c6b7f047d5639503dda1 boost_1_77_0_rc1.7z 5347464af5b14ac54bb945dc68f1dd7c56f0dad7262816b956138fc53bcc0131 boost_1_77_0_rc1.tar.gz d2886ceff60c35fc6dc9120e8faa960c1e9535f2d7ce447469eae9836110ea77 boost_1_77_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 Release managers

3 3

[multiprecision/mpc][math/quadrature] Why boost::multiprecision::exp gets stuck when evaluating complex-valued integral?
by Kirill Kudashkin 05 Aug '21

05 Aug '21

Dear all, I have encountered a problem while using Boost C++ libraries ( multiprecision/mpc.hpp, math/quadrature) which I cannot resolve. This problems appears when running the following piece of code || |#include <boost/math/constants/constants.hpp> #include <boost/math/quadrature/exp_sinh.hpp> #include <boost/multiprecision/mpc.hpp> #include <boost/multiprecision/mpfr.hpp> #include <boost/math/special_functions/fpclassify.hpp> namespace mpns = boost::multiprecision; typedef mpns::number<boost::multiprecision::mpc_complex_backend <50> > mpc_type ; typedef mpc_type::value_type mp_type ; int main() { using boost::math::constants::root_pi ; mpc_type z{mp_type(1),mp_type(1)} ; auto f = [&](mp_type x) { //actually I did not test if all these conditions are needed... if (boost::math::fpclassify<mp_type> (x) == FP_ZERO) { return mpc_type(mp_type(1)) ; }; if (boost::math::fpclassify<mp_type> (x) == FP_INFINITE) { return mpc_type(mp_type(0)) ; }; mp_type x2 = mpns::pow(x,2U) ; if (boost::math::fpclassify<mp_type> (x2) == FP_ZERO) { return mpc_type(mp_type(1)) ; }; if (boost::math::fpclassify<mp_type> (x2) == FP_INFINITE) { return mpc_type(mp_type(0)) ; }; mpc_type ex2 = mpns::exp(-z*x2) ; if (boost::math::fpclassify<mpc_type> (ex2) == FP_ZERO) { return mpc_type(mp_type(0)) ; }; return ex2 ; } ; mp_type termination = boost::math::tools::root_epsilon <mp_type> () ; mp_type error; mp_type L1; size_t max_halvings = 12; boost::math::quadrature::exp_sinh<mp_type> integrator(max_halvings) ; mpc_type res = integrator.integrate(f,termination,&error,&L1) ; mpc_type div = 2U*mpns::sqrt(z) ; mpc_type result = (mpc_type(root_pi<mp_type> ())/div) - res ; return 0; } | ||Namely, the problem appears when evaluating the exponent. The code is compiled without any problems, but hangs on computing | mpc_type ex2 = mpns::exp(-z*x2) ;| It was possible to go into the function while debugging. It crashed eventually, when the compiler reached "unable to resolve non-existing file.../src/init2.c". I let it run for a while checking the call stack. It appears that the programs is stuck atcalling ___gmpn_sub_n_coreisbr(). Or better, in the call stuck it appeared frequently. I did several tests. The real-valued version (with mpfr_backend <2000>) works without any problems. cpp_complex_backend <100> works fine, but I could not test higher precision yet, since it is much slower. I found a work-around which is not ideal. Namely, mpc_type ex2 = mpc_type(mpns::exp(x2)) ; mpc_type ezx2 = mpns::pow(ex2,-z) ; works fine with mpc_complex_backend <2000>. The lambda-function as it is declared in the code above works and yields correct numbers. The problem appears when it is called from the integrator. My system. I use openSUSE Tumbeleweed. I installed boost libraries as provided by |boost_1_76_0-gnu-mpich-hpc-devel.| Complier -> g++, cppStandard gnu+17. I check that I have all libs, e.g. libgmp, libmpc, libmpfr and etc. All headers are present (the programs is complied without any warnings). Sorry for a lengthy question. Thank you in advance and Best wishes, Kirill ||

1 0

Reminder: The Master branch will be closing for the 1.77.0 release on WEDNESDAY 4-August
by Marshall Clow 04 Aug '21

04 Aug '21

Release calendar here: https://www.boost.org/development/index.html — Marshall

8 17