- Boost - lists.boost.org

Re: [boost] [review] [text] Text formal review
by Bjorn Reese 13 Jun '20

13 Jun '20

Why does Boost.Text contains trie types in their own boost::trie namespace?

2 1

[epochs] Strict vs. lax mode and epoch assignment reports
by Joaquin M López Muñoz 13 Jun '20

13 Jun '20

For those interested in the epoch proposal: * I've included a discussion on an alternative set of rules for epoch assignment dubbed "lax mode": https://github.com/joaquintides/boost_epoch#strict-vs-lax-mode This mode is somewhat more comprehensive that the original, strict mode, in the sense that more libs would progress to higher epochs. Comments welcome on which mode fulfills best the goals of the proposal. * I've written a utility to automate epoch assignment from a core set of human-decided lib rejections: * Strict mode: https://github.com/joaquintides/boost_epoch/blob/master/epoch_report.md * Lax mode: https://github.com/joaquintides/boost_epoch/blob/master/lax_epoch_report.md These are illustrative examples pretty much dependent on what libs are determined to be subsumed by the C++ standard or more modern Boost libs. You can try modifying this (https://github.com/joaquintides/boost_epoch/blob/master/epoch_report/booste… ) and running the epoch report tool to see the results. Best, Joaquín M López Muñoz

1 0

[Nowide] Opinion on slightly expanding the scope: LFS and more generic UTF-8 wide<->narrow conversion
by Alexander Grund 12 Jun '20

12 Jun '20

Hi all, just wanted to gather opinions on 2 changes I'd like to make to Boost.Nowide which go slightly above the initial goal: 1. Make detail implementations of widen/narrow public. - Mainly https://github.com/boostorg/nowide/blob/develop/include/boost/nowide/detail… which does templated conversion from/to wide strings which might be useful in generic contexts - But also the underlying UTF decoding/encoding templates initially extracted from Boost.Locale https://github.com/boostorg/nowide/blob/develop/include/boost/nowide/detail… I figured (and experienced) that those might be useful for consumers of Nowide as when they already use those UTF-8 APIs they might have other interface code which needs translation from/to wide strings, so exposing the existing code as a feature might make sense. Basically this would put them under boost::nowide::utf namespace instead of in the detail namespace. I guess I don't need to retain the old ones or put in forwarding headers, do I? 2. As requested and implemented over 2 PRs (last one still open: https://github.com/boostorg/nowide/pull/104) Large files are now supported by boost::nowide::filebuf (technically only used on Windows) but the implementation is pretty portable as e.g. Tests on Unix do use boost::nowide::filebuf. This is done by implementing ftell/fseek via _ftelli64/ftello and configure-time checking availability. As C++ is lacking C-Style file manipulation functions portably working with LFS I think a similar reasoning as above can be applied: It exists, it works and can be useful more generically so moving it out of the detail namespace might make sense. Opinions? Ideas? Regards, Alex PS: If anyone with filesystem experience would like to review #104 or at least glance over it, it would be appreciated.

2 3

How to clean boost::asio::streambuf before writing to it?
by Jupiter 10 Jun '20

10 Jun '20

Sorry, this is really a silly question, but I could not find a clear API in streambuf reference, I have following code to call PacketData in a loop, the buffer.get() looked to accumulate previous data in the buffer, so I should call buffer.clear() before calling buffer.get(), but apparently there no ‘clear’ in boost::asio::basic_streambuf. PacketData(const msgpack::sbuffer &sb, boost::asio::streambuf &buffer)) { ....... std::ostream os(buffer.get()); os.write((char *)&header, sizeof(header)); os.write((char *)sb.data(), sb.size()); ....... } Thank you. Kind regards, - jh -- "A man can fail many times, but he isn't a failure until he begins to blame somebody else." -- John Burroughs

3 4

Re: [boost] [Boost-users] Impossible to download a boost source from bintray: 403 Forbidden
by Marshall Clow 08 Jun '20

08 Jun '20

On Sat, Jun 6, 2020 at 10:34 AM Eisuke Kawashima via Boost-users < boost-users(a)lists.boost.org> wrote: > Dear All, > > I cannot download a boost source from bintray, e.g., > https://dl.bintray.com/boostorg/release/1.73.0/source/boost_1_73_0.tar.bz2 > returns 403 Forbidden. > OTOH, sourceforge works: > > https://sourceforge.net/projects/boost/files/boost/1.73.0/boost_1_73_0.tar.… > . > > We (boost) have reached our monthly allocation of bandwidth donated by Bintray/JFrog (Thanks, JFrog!) We're trying to figure out how we blew through that much bandwidth in 5+ days. (10s of TB). I will post here again when we know more. -- Marshall

2 2

problem with boost test matrix for serialization related to changes in file system?
by Robert Ramey 08 Jun '20

08 Jun '20

I made a few checkins to the serialization library which I had previously tested on my working system. But Now I'm getting some very weird errors in the Boost Test matrix: https://www.boost.org/development/tests/develop/developer/serialization.html Anyone who has some useful insight would be free to chime in. According to P Dimov, Filesystem is guilty and i should request help from andrey semashev - so here it is. Robert Ramey

3 3

[review][LEAF] Review of LEAF starts today : May 22 - May 31
by Michael Caisse 08 Jun '20

08 Jun '20

The Boost formal review of Emil Dotchevski's LEAF (Lightweight Error Augmentation Framework) library will take place from May 22 through May 31st. LEAF isn't just another error reporting library in the family of expected-like types. It provides a unique take on error handling which plays into usability, flexibility, and performance. Every software developer must deal with handling errors which makes this review relevant to all. Please participate! I will be grateful to receive a review based on whatever level of effort or time you can devote. LEAF is brought to us by Emil Dotchevski, the author of Boost.Exception. Similar to Boost.Exception, this library allows arbitrary error objects to be returned; however, unlike Boost.Exception it does not require dynamic memory. The library can be used with or without exception handling. The LEAF documentation highlights the following features: * Efficient delivery of arbitrary error objects to the correct error handling scope. * No dynamic memory allocations. * Compatible with std::error_code, errno and any other error code type. * Can be used with or without exception handling. * Support for multi-thread programming. "LEAF is designed with a strong bias towards the common use case where callers of functions which may fail check for success and forward errors up the call chain but do not handle them." LEAF offers a pattern matching facility to specify which errors to handle and how to handle them. Take a look at the 5-minute Introduction. <https://zajo.github.io/leaf/#introduction> You can find the source code to be reviewed here: <https://github.com/zajo/leaf/tree/review> You can find the documentation here: <https://zajo.github.io/leaf/> The documentation includes a tutorial, examples, reference, design rationale, and comparisons to other error handling approaches/libraries. There is a benchmark document also: <https://github.com/zajo/leaf/blob/master/benchmark/benchmark.md> and a whitepaper: <https://github.com/zajo/leaf/blob/master/doc/whitepaper.md> Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including LEAF 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. Happy coding - michael -- Michael Caisse Ciere Consulting ciere.com

14 42

[atomic] Bikeshedding over address-free waiting/notifying operation names
by Andrey Semashev 07 Jun '20

07 Jun '20

Hi, As some of you may know, C++20 added new waiting/notifying operations to std::atomic: wait, notify_one and notify_all. These operations are not address-free, i.e. their implementation is allowed to use process-local addresses of the atomics as keys. In particular, it means you can't use them for inter-process communication. In Boost.Atomic I intend to provide address-free variants as well, where possible, and I'm thinking about the naming scheme for them. Currently, I'm using the "_address_free" suffix, so we have wait_address_free, notify_one_address_free and notify_all_address_free. The "address-free" term comes from the C++ standard, but the resulting names seem a bit long. Maybe there are better suggestions? Thanks.

6 11

[epochs] Boost conditional dependency map
by Joaquin M López Muñoz 05 Jun '20

05 Jun '20

As part of the epoch proposal, I've written a small toolchain to generate a so-called Boost conditional dependency map: https://github.com/joaquintides/boostcdmap/ Such a map gives, for each Boost module and each epoch Boost03, ... , Boost20, the dependencies of the module under the given epoch (which may vary across epochs). The actual map for Boost 1.73 is provided at: https://github.com/joaquintides/boostcdmap/blob/master/boostcdmap.1.73.0.js… The conditional dependency map is a key asset for the automation of epoch assignment; I'll elaborate on this point in the upcoming days. As always, comments welcome. Best regards, Joaquín M López Muñoz

1 0

[epochs] Internal relevance in post-C++03 Boost of Boost03 components vs. standard equivalents
by Joaquin M López Muñoz 05 Jun '20

05 Jun '20

For those of you who are following the discussion on epochs, I've just prepared a report on the relevance of "legacy" components intra-Boost for these Boost libs that require C++11 (or higher) to work: https://github.com/joaquintides/boost_epoch/blob/master/boost_vs_std_intern… Quoting from the report: "It can be seen that (direct) usage of Boost03 components is residual (and in some cases due to backwards compatibility rather than for their functionality). We can draw then the conclusion that newer Boost libraries are already dismissing legacy dependencies when the standard environment offers alternatives." Best, Joaquín M López Muñoz

2 3