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

A solution to return dynamic strings without heap allocation. Any interest?
by Roberto Hinz 09 Oct '19

09 Oct '19

Hi all, I haven't been succesful at attracting interest in a formatting library [1] I've been working lately. But recently I realized that part of it could be isolated as a small standalone library that could solve an old common troublesome situation in C++: Suppose you need to create a function that returns/provides a string whose content and size is unknown at compilation time. The first approach is to make it return a `std::string`. But if it need to be usable in environments like bare-metal real-time system, then one usually makes it take a raw string as an output argument, more or less like this: struct result{ char* it; bool truncated; }; result get_message(char* dest, std::size_t dest_len); But this is clearly not a perfect solution since there's nothing really effective the caller can do when get_mesage fails because of the destination string being is too small. So I present the `outbut` abstract class. It somehow resembles `std::streambuf`, but with a simpler and lower level design, which is the result of many attempts looking for the best performance [2] and usability in my formatting library. Afaics, it does not require a hosted C++ implementation, though I would like someone else to confirm that. Now the caller of `get_message` has to choose or create a suitable class type deriving from outbuf, that dictates where the message is written to. For example, if the user wants to get a `std::string`, then `string_maker` will do the job: #include <boost/outbuf/string.hpp> // ... boost::outbuf::string_maker<false> msg; get_message(msg) std::string str = msg.finish(); Or, if one wants it to write into a raw string, then use `cstr_writer` char buff[buff_size]; boost::outbuf::cstr_writer csw(buff, buff_size); get_message(csw); auto result = csw.finish(); if (result.truncated) { // ... Those `finish` functions above do not belong to `outbuf`. They are defined in the concrete derived types only. It's solely by convention that they share the same name. Yes, using `string_maker` still leads to heap allocation and `cstr_writer` to string truncation. The problem isn't solved by these. However, a string object is never the final destination. So the user could rather use another class that writes the message directly into the final destination ( output console, a log file, an LCD display or whatever ). It is not difficult to implement concrete subtypes of `outbuf`. `outbuf` is actually a type alias: template <bool NoExcept, typename CharT> class basic_outbuf; using outbuf = basic_outbuf<false, char>; using outbuf_noexcept = basic_outbuf<true, char>; That `NoExcept` template parameter is perhaps the controversial part. It is not present originally in my formatting library. Besides the destructor, `basic_outbuf` has only one virtual function: `recycle()`, and it is declared as `noexcept(NoExcept)`. This is the only effect the `NoExcept` template parameter has. All other functions are guaranteed not to throw. Hence, by taking a `outbuf_noexcept&` parameter, a function states that the destination must not throw. That might be particularly good if such object comes from another module and we must avoid exceptions crossing modules boundaries. On the other hand, if a function takes an `outbuf&`, then it also accepts `outbuf_noexcept&`, because `basic_outbuf<true, CharT>&` derives from `basic_outbuf<false, CharT>`. When using `string_maker` you can choose between the two kinds. `string_maker<true>` derives from `basic_outbuf<true, char>&`. So if any exception raises from its internal `std::string`, then it is caught by a try/catch(...) block, stored as an `exception_ptr` and rethrown by `finish()`. This has the undesirable effect of delaying its proper handling ( after all, we rather stop what's being doing as soon as possible when an error appears ). So I think the recommendation would be to use `string_maker<false>&` if possible, and `string_maker<true>&` only if necessary. The reason why I think it's controversial is that it makes `recycle()` violates the Lakos Rule. And although the Lakos Rule is not a requirement in boost (afaik), I was wondering whether this library could interest LEWG in future as well. Anyway, this whole noexcept idea is not a central part of this library and can it be removed. Now, the other topic is how to implement that `get_message` function, i.e., how to write into an `outbuf` object. One can use `puts` and `putc` functions to insert string and chars. One can also use `fmtlib` through an output iterator adapter. Or one can write directly in the buffer. But I will ask you to read the doc [3] for that. It's a quick read, quicker than this email. The repository is: https://github.com/robhz786/outbuf I would prefer it to be part of Boost.Core instead of being a standalone library, and also to remove the `outbuf` namespace. But that is up to you. Best regards, Roberto [1] The Stringify library: https://github.com/robhz786/stringify [2] The great performance of Stringify is mainly thanks to the design of outbuf ( named there as `output_buffer` ): https://robhz786.github.io/stringify/doc/html/benchmarks/benchmarks.html#be… [3] "Writing into and outbuf object" https://robhz786.github.io/outbuf/doc/html/index.html#boost_outbuf.overview…

5 13

Requesting endorsements of Boost.STLInterfaces for review
by Zach Laine 20 Sep '19

20 Sep '19

As mentioned a couple of weeks ago, I started a small library that was an updated iterator_facade. It is now a still-smallish library called stl_interfaces that includes a pre-C++20 implementation of view_interface, and analogous templates iterator_interface (a cross between Boost.Iterator's iterator_facade and iterator_adaptor), and container_interface. Each of these makes it easier to write a view, iterator, or container, respectively. Using container_interface, I was able to write a version of static_vector in which I implemented only 21 member functions, and the template provided the other 40(!) functions. The library is C++14 and later. There is an inline v1 namespace for the C++14 implementations, and an experimental non-inline v2 namespace with implementations using C++20 standard concepts. The part using C++20 concepts requires GCC 8 or 9, and cmcstl2 (more info on that on the Github page). Github page: https://github.com/tzlaine/stl_interfaces Online docs: https://tzlaine.github.io/stl_inteTherfaces/doc/html/index.html <https://tzlaine.github.io/stl_interfaces/doc/html/index.html> Oh, and if you're willing to act as review manager, please let me know. Zach

9 17

Re: [boost] [Boost-users] License Issue with boost_intrusive
by Michael Caisse 27 Aug '19

27 Aug '19

Copying to dev ML. On 8/22/19 12:05, Gerald Wiltse via Boost-users wrote: > During an annual third-party audit of our source code, boost intrusive > was flagged as containing unlicensed code. Specifically, there are > several pieces of code in this file which are explicitly attributed to > external parties on external websites, which still exist and show no > license. > > https://github.com/boostorg/intrusive/blob/develop/include/boost/intrusive/… > > https://github.com/boostorg/intrusive/blob/develop/include/boost/intrusive/… > > > Original sources: > http://stackoverflow.com/questions/11376288/fast-computing-of-log2-for-64-b… > http://www.flipcode.com/archives/Fast_log_Function.shtml > > I don't claim to be a license expert. I've read a lot over the years, > but this is the first time that I've actually been between an attorney > and a codebase having to figure out practical implications of a scenario > like this. > > I first want to make sure that Boost committee is aware of this situation. > > Second, I would like to know what the official conclusion would be from > the Boost Committee about the license implications in cases like these. > Maybe it has come up before and is well established. On the surface, the > implications seems ambiguous to me when: DEVELOPER_A takes unlicensed > code off the internet, prefixes it with a comment that says "Thanks to > DEVELOPER_B ", then prefixes the whole file with a file-level copyright > notice that says "COPYRIGHT DEVELOPER_A", and then says it's > distributed under BSL-1.0 license, and then the boost team > re-distributes the source code. > > Internally at my company, there was little discussion about it. There > is no room for ambiguity, so the directive from management was to delete > the file from our SCM system completely and ensure it never is included > in our products. VERY fortunately, deleting it doesn't seem to have > broken our builds. In future cases like this, that's really not what we > want to be doing with your OSS libraries for obvious reasons. So, I'd > like to know if there's any chance this situation changes in a future > version of Boost (I.E., the code be removed/re-written with clean-room > approach, etc). > > Regards, > Jerry > > Gerald R. Wiltse > jerrywiltse(a)gmail.com <mailto:jerrywiltse@gmail.com> > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > https://lists.boost.org/mailman/listinfo.cgi/boost-users >

8 8

Set deadline_timer expired_at realtime clock 0 minute and repeat
by JH 27 Aug '19

27 Aug '19

Hi, How can I set deadline_timer expired at real clock absolute time at 0 minute, then repeat every minute? So it should expired at: 13:40:00, 13:41:00, 13:42:00 and so on? Thank you. Kind regards, - jupiter

2 7

Becoming the new maintainer of Boost.Functional/Factory (value_factory and factory)
by Glen Fernandes 26 Aug '19

26 Aug '19

Tobias (see forwarded e-mail below) has kindly agreed to allow me to become the maintainer of boost::factory and boost::value_factory (in Boost.Functional). I'll be revising the implementation of both for the next Boost (1.72) release, to: * Support r-value arguments * Use variadic templates to support arbitrary arguments * Support allocators that are final * Support allocators that use non-raw (fancy) pointers * Support BOOST_NO_EXCEPTIONS environments * Improve compilation times (drop Boost.Preprocessor usage) I'll add myself to the appropriate repository teams and update the library information accordingly. Glen ---------- Forwarded message --------- From: T.Schwinger <tschwinger(a)isonews2.com> Date: Mon, Aug 26, 2019 at 5:38 AM Subject: Re: Maintaining Boost.Functional value_factory and factory To: Glen Fernandes <glen.fernandes(a)gmail.com> Hi Glen, On 25.08.19 19:46, Glen Fernandes wrote: > I'd like to assume maintenance of factory/value_factory in > Boost.Functional. Among other things, update them to support r-value > references (when the compiler supports it), as well as simplify the > implementation for when the compiler supports variadic templates. > Along with other work going forward. [...] > If you have no objections let me know. No objections - to the contrary: I'm grateful. Thank you for taking care of it! Best, Toby

1 0

Compliance with Boost copyright and license guidelines
by pbristow＠hetp.u-net.com 23 Aug '19

23 Aug '19

Prompted by some recent discussion of Boost license and copyright info by the Debian package team, I have recently been checking on the Boost.Multiprecision library and run the Boost inspect program https://www.boost.org/doc/libs/1_70_0/tools/inspect/ (originally written by Beman Dawes in 2003 and revised several times since). I’ve made some minor cosmetic changes to the program and the rather sparse documentation to make it easier to use by library authors and give a bit more info. It checks on compliance with https://www.boost.org/development/requirements.html. It’s use has been a little neglected recently but I conclude that we are not doing well enough in providing the proof of copyright and license that we promise. The results of my run of inspect on the boost/lib folder using develop branch are not pretty Problem counts: 1790 files missing Boost license info or having wrong reference text 1682 files missing copyright notice (but not I suspect quite as bad as they look – some items probably do not need copyright and license). Now that the 1.71 release is out bar a little shouting, I wonder if we should focus on improving compliance for the next release? I’d like to propose 1 A boost/tools/inspect/develop branch to refine the inspect program a little and improve the documentation (I have done something on this already for my education and use). 2 Discussion of the bad results (zip attached) to try to find why there are so many reports and to decide what to do. 3 Encourage all authors to run inspect on their library locally and try to remedy the items missing. 4 I suspect that many libraries will have items missing but the authors are also missing. So someone from the community maintenance team will need to take over and make some decisions on what to do. Often just providing a copyright claim from the obvious author and Boost license will suffice? 5 Try to improve the compliance with other guidelines. For example. there are many libraries that are failing to prevent with min and max macros for what of a couple of brackets. Usually (std::numeric_limits<>::max)(). All these will trip up Windows users in a puzzling way. Please can we just fix these? Views? Paul PS My halo is shining brightly 😉 Boost.Multiprecision has a problem count of zero 😊 (and I’m working on Boost.Math) Boost Inspection Report Inspect version no 3.1.15 Run Date: 08:44:19 UTC, Saturday 17 August 2019 Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) Copyright Boost 2019 boost-no-inspect Inspection from path "libs" including subfolders. Totals: 52355 files scanned 4351 directories scanned (including root) 3472 problems reported Problem counts: 1790 files missing Boost license info or having wrong reference text 1682 files missing copyright notice Worst Offenders: outcome 940 metaparse 556 polygon 228 python 194 beast 192 Summary: algorithm (4) array (2) asio (12) … Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK

14 34

Re: [boost] crc.hpp:569 msvc warning C4800
by Kenneth Porter 22 Aug '19

22 Aug '19

This appears not to have made it into 1.71.0. I had to edit crc.hpp:569 to silence the warning. --On Saturday, April 13, 2019 1:35 PM -0700 Kenneth Porter via Boost <boost(a)lists.boost.org> wrote: > <https://github.com/boostorg/crc/pull/2> > > Visual Studio 2010-2019 issue this warning for crc.hpp line 569: > > warning C4800: "'int' : forcing value to bool 'true' or 'false' > (performance warning) > > bool const quotient = remainder & high_bit_mask; > > Replace with: > > bool const quotient = (remainder & high_bit_mask) != 0;

1 0

boost high precision timer and boost io_service
by JH 22 Aug '19

22 Aug '19

Hi, I am currently running boost::asio::deadline_timer to transmit data every minute, the requirement needs the interval accurate, if the first data sending at 10:00:05, the next needs be 10:01:05 and so on, but my data sending time shifting every 2 seconds I need to fix it. I am not sure if the boost high precision timer can fix it, it seems to me like a realtime requirement. My whole application is based on boost::asio::io_service in a single thread on Linux embedded system, can the boost high precision timer fix the problem or will the the boost multithreading fix the problem or there might be no chance to match the requirement simply because Linux is not a realtime OS? Appreciate your insight advice. Thank you. Kind regards, - jupiter

4 5

[release] Boost 1.71.0
by Michael Caisse 21 Aug '19

21 Aug '19

Release 1.71.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 1 new library (Variant2) and numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.71.0> You can also download directly from: <https://dl.bintray.com/boostorg/release/1.71.0/> 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 Marshall Clow, Michael Caisse

3 2

[release] Boost 1.71.0 Release Candidate 2 available
by Michael Caisse 20 Aug '19

20 Aug '19

The release candidates for the 1.71.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.71.0/source/> The SHA256 checksums are as follows: 1b3949ffddf56129141032542523920034f2e69775fb9332a52ba37c548dbf35 boost_1_71_0_rc2.7z d73a8da01e8bf8c7eda40b4c84915071a8c8a0df4a6734537ddde4a8580524ee boost_1_71_0_rc2.tar.bz2 96b34f7468f26a141f6020efb813f1a2f3dfb9797ecf76a7d7cbd843cc95f5bd boost_1_71_0_rc2.tar.gz 85a94ac71c28e59cf97a96714e4c58a18550c227ac8b0388c260d6c717e47a69 boost_1_71_0_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

5 6