- Boost - lists.boost.org

[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

[LEAF] A sort of review
by Andrzej Krzemienski 04 Jun '20

04 Jun '20

Hi Everyone, According to the schedule the review period of LEAF should have ended, but since I haven't heard a clear announcement, I assume it isn't too late to provide feedback. I regret that I cannot afford to make a full review of the library that Emil deserves. So this will be just "notes". I didn't have time to study the implementation of the library. I only read most of the documentation (documentation is really good), tried some toy examples to see if I can brake it (didn't manage to), and participated in Boost discussions on the subject. Only from this am I confident that the library has been well designed. Its goals are clearly set and sound, and the designed explained in the docs. We have competing libraries in Boost for error handling (Boost.Outcome) but they put accent on different things, and besides Boost is already known to host competing designs and approaches to the same problem. The need to transport arbitrary number of information collected at different levels of call stack is a sound goal, and well addressed in LEAF. The choice to put error data on the stack is great, and well understood and explored, for instance in https://www.research.ed.ac.uk/portal/files/78829292/low_cost_deterministic_… I find function preload() (https://zajo.github.io/leaf/#tutorial-preload) really great and novel. This is the first big C++ library that I know that implements it. This really makes the error reporting code brief, clean and bug-free. Some people have reported that the usage of multiple lambdas in try-catch-like statements is inconvenient. It is; but I think it works to the advantage of the library. My approach to handling errors based on skipping dependent operations ( https://akrzemi1.wordpress.com/2019/04/25/handling-errors-is-canceling-oper…) is that you report errors (start the "stack unwinding") in many places, keep the most functions error neutral, and you stop the "stack unwinding" only in very few places. In this approach, only very few places in program code would have to put these try-catch statements with lambdas, and the clumsiness of the syntax would encourage the users to adapt the methodology "stop unwinding in very few places". My only criticism of the library is that it makes a serious design choice to use a thread-local storage and fails to communicate it clearly to potential users in the documentation. It is ok for the library to make the choice to use TLS, but it is not ok to omit it from the "design choices" in documentation. I wouldn't bring it up if the documentation was poor; but because it is so high-standard, it strikes me that this information is missing. The reservations about TLS have nothing to do with performance. First, some platforms do not provide it. But as Bjorn Reese indicated, the same functionality could be implemented with a global lock-free map with thread IDs as keys, and no TLS would be required. Second, and I think more serious, is that thread-local solutions (including the global hash map with thread IDs) play very badly with coroutines: in a coroutine world a function can start executing in one thread, and finish executing in a different one. All those TLS-based solutions compile and may pass tests but are likely to fail with random results or crashes later. Many good programmers do not realize this. Emil informs me that this problem could be worked around by manually propagating some error information at the point where coroutines are managed. And I trust him on that. But in order for the programmer to do this manual part correctly, she has to know that this problem exists, and that she has to do it. This has to be stated prominently in the documentation along with the example how to do it. This criticism is only about the documentation. Not the design or implementation. I would not use LEAF for production applications I work with. The reason is that I am satisfied c++ exceptions and I find their cost tolerable in most of the places. In the remaining parts, usually low-level, where the performance or explicit control flows are important, I do not care about the detailed information about the failure, other than an integer code. But this is just my use case. My familiarity with the domain: I report failures in my code :). I study the topic of reporting failures effectively a lot. I follow the progress of ISO C++ Committee on the subject. I have co-authored the documentation of Boost.Outcome. As I said, I didn't review the implementation, so the Review Manager will consider it in weighing my opinion, but my recommendation is to **ACCEPT** LEAF into Boost. Thank you, Emil, for writing and sharing this library. Regards, &rzej;

3 3