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

Re: [boost] Unconditional conditional building is cursed"
by Nikita Kniazev 27 Aug '21

27 Aug '21

> But the problem has nothing to do with silently not building libraries. It's > caused by libraries assuming that Boost.Config is at ../config. Both have the same root cause -- no way to turn off these build checks. If the checks are not needed there is no need to import Boost.Config and assume its location too. P.S. I do not understand how to reply in the Boost mailing lists, please do not blame me if the message went to the wrong thread, I expressed my frustration about that … [View More]

3 2

Unconditional conditional building is cursed
by Nikita Kniazev 26 Aug '21

26 Aug '21

Some libraries (Context, Contract, Fiber, Json, Math, Nowide) are built conditionally and use checks from the Config library to do that (`import ../../config/checks/config : requires ;`). Apparently, it happens to be a PITA for some consumers. Vcpkg had to hack around that and update the hack every Boost release, but Boost 1.76 revealed problems in it ( https://github.com/boostorg/build/issues/724) and Boost 1.77 is blocked by it (https://github.com/microsoft/vcpkg/pull/19556#issuecomment-… [View More]

2 1

Does boost have an assert that works nicely with constexpr evaluation, and if not should we add one?
by Ivan Matek 25 Aug '21

25 Aug '21

As you may know assert does not play nicely with constexpr evaluation. But std::is_constant_evaluated/if consteval gives us a way to check when the execution happens. https://www.godbolt.org/z/dfder8h16 Does something like this exist in boost, and if not would that be a nice addition? I can not figure out how to support line numbers, filename in a same way assert does, since assert will obviously just take the line info from where it is called. P.S. smart_assert is just a first name I … [View More]

4 7

Need cancel() on async_resolve() to callback the resolve handler immediately
by sandeep m.v 25 Aug '21

25 Aug '21

Hi All, I'm looking for a solution for below problem. We're using async_resolve() to perform DNS resolution using boost::asio::ip::tcp::resolver. In few instances probably during network connectivity issues, async_resolve is taking more time. When our application timeouts in 15seconds while waiting for DNS resolution, cancel() is called on resolver. But, that doesn't callback to resolve handle immediately. When I tried to search for this, it looks like, when a cancel() is called on resolver, … [View More]

4 8

BOOST_IS_CONSTANT_EVALUATED_INT(integer-expression)(integer-expression)
by Robert Ramey 24 Aug '21

24 Aug '21

A couple of questions regarding the above new boost config macro. a) I note that this "breaks the pattern" of BOOST_NO_... which I was expecting. I've got no complaint about this, just like being consistent when possible. b) My intended usage is something like: template<typename T> constexpr interval<T> get_interval(const & T t){ return BOOST_IS_CONSTANT_EVALUATED_INT(t) ? interval<T>(t, t) : interval<T>( std::numeric_limits<T>::min(), … [View More]

3 8

Strange b2 headers problem
by Edward Diener 24 Aug '21

24 Aug '21

I switched my main boost repository from the 'develop' branch to an earlier tagged boost release to try something out in that earlier release. Everything went fine with switching the main repository and all submodules. I wiped out all the header links from the boost subdirectory and I tried b2 headers, only to get: error: Cannot create link boost\property_map\parallel\basic_reduce.hpp to libs\property_map_parallel\include\boost\property_map\parallel\basic_reduce.hpp. error: Link … [View More]

2 3

[release]Boost 1.77.0
by Marshall Clow 22 Aug '21

22 Aug '21

Release 1.77.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 two new libraries and numerous enhancements and bug fixes for existing libraries. * Describe: A C++14 reflection library, from Peter Dimov. Provides macros for describing enumerators and struct/class members, and … [View More]

4 7

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/… [View More]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 [View Less]

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