- Boost - lists.preview.boost.org

[text] Copyright notices
by Phil Endecott 20 Jun '20

20 Jun '20

Dear All, Looking at the proposed Boost.Text source, I find that: 1. Many files don't have a copyright header. Random example: https://github.com/tzlaine/text/blob/master/include/boost/text/unencoded_ro… I guess this is an oversight and is easily fixed. 2. Some files have a copyright header which is not the Boost licence. Example: https://github.com/tzlaine/text/blob/master/include/boost/text/transcode_al… This one has a requirement that binary distribution includes the copyright notice, which is not a requirement of the Boost licence, and will be problematic for some users. Are the only affected files the SIMD implementation, (c) Robert N Steagall? If so, can this be disabled (by default?) by the user to avoid the copyright notice requirement? 3. The documentation includes a Unicode copyright notice: https://tzlaine.github.io/text/doc/html/boost_text__proposed_/unicode_copyr… This also includes a requirement that the copyright notice is included in data files, software or associated documentation, whatever that means. It's not clear to me what this actually covers; again, can some functionality (e.g. UTF-N-to-M conversion without normalisation) work without the Unicode data? Regards, Phil.

8 15

[text] Comparison with Unicode features of Boost.Locale
by Phil Endecott 19 Jun '20

19 Jun '20

Dear Zach & others, Boost already has some Unicode functionality in Boost.Locale. Would you like to compare the pros/cons of each? Regards, Phil.

3 3

[text] SIMD UTF-8 decoding
by Phil Endecott 18 Jun '20

18 Jun '20

Dear All, I have been looking at the UTF-8 decoding code in the proposed Boost.Text, as this is a problem I've looked at myself in the past. I've mentioned an issue with the copyright in another message. Here are my other observations. 1. The SIMD code is x86-specific. It doesn't need to be; I think it could use gcc's vector builtins to do the same thing and be portable to other SIMD implementations. (Clang provides the same builtins; I'm not sure about what you need to do on MSVC/Windows.) See: https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html 2. The SIMD code only seems to provide a fast path for bytes < 0x80, falling back to sequential code for everything else. I guess I was expecting something more sophisticated. 3. The code used for bytes >= 0x80, and in all cases for non-x86, is here: https://github.com/tzlaine/text/blob/master/include/boost/text/transcode_it… around lines 400-560. It implements a state machine, which surprises me; it takes much less code and gives better performance if you write out the bit-testing and shifting etc. explicitly. This seems to be about 50% slower than my existing UTF-8 decoding code. 4. There aren't enough comments anywhere in the code I've looked at! Regards, Phil.

4 6

[container] Proposal for ring queues
by Andrey Semashev 17 Jun '20

17 Jun '20

Hi, Some time ago I have proposed to include ring_queue and small_ring_queue containers to Boost.Container: https://github.com/boostorg/container/pull/121 The ring queues work similarly to std::queue with the main difference being that they use a ring buffer internally to store elements. The small_ring_queue also allows to allocate a static storage for a fixed amount of elements. The benefit of this is that dynamic memory allocations can be practically avoided when the number of enqueued elements does not exceed some limit. In his reply in that PR Ion was not very enthusiastic about including these containers into Boost.Container mostly because (a) there was presumably not much interest from users and (b) because the current implementation requires C++17 while Boost.Container supports C++03. I would like to ask if there is interest in the community for these kinds of containers. I know I would find them useful, and at least one person commented in the PR to the same effect. However, I would still like to see if more people need this. If there is interest, what would be the preferred course of action? 1. Should we work on inclusion into Boost.Container or maybe some other library? Candidates? Boost.CircularBuffer was mentioned in the PR, although I'm not sure it is suitable for these components. Creating a new submodule is also a possibility, although it seems like an overkill. 2. Somewhat related to p.1, what minimum C++ version is preferred. E.g. if we agree that Boost.Container is the right place for these components, I could work on lowering minimum C++ version, although C++03 would complicate things considerably. Thanks.

9 28

Re: [boost] [text] Copyright notices
by Andrey Semashev 16 Jun '20

16 Jun '20

On 2020-06-16 17:43, Hans Dembinski wrote: >> On 16. Jun 2020, at 16:41, Hans Dembinski <hans.dembinski(a)gmail.com> wrote: >> >>> >>> On 16. Jun 2020, at 16:32, Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: >>> >>> On 2020-06-16 16:45, Hans Dembinski via Boost wrote: >>>>> On 16. Jun 2020, at 14:53, Niall Douglas via Boost <boost(a)lists.boost.org> wrote: >>>>> >>>>> On 15/06/2020 17:19, Phil Endecott via Boost wrote: >>>>> >>>>>> Are the only affected files the SIMD implementation, (c) Robert N >>>>>> Steagall? If so, can this be disabled (by default?) by the user >>>>>> to avoid the copyright notice requirement? >>>>> >>>>> If that's *the* Bob Steagall I'm almost certain he'll relicence his code >>>>> under Boost if you ask him. >>>> I think a multi-platform library like Boost should avoid using SIMD intrinsics and write the code so that the auto-vectorisers of the compilers understand it - if that is possible. I don't claim it is possible here, but I have a lot of trust in the auto-vectorisers of gcc and clang. Godbolt is very helpful in designing code that can be auto-vectorised well. >>> >>> In my experience, auto-vectorization is useless in all but trivial cases. >> >> Care to give me an example? > > I don't know what you consider trivial, but these examples here listed under "vectorizable" do not look trivial to me. > > https://gcc.gnu.org/projects/tree-ssa/vectorization.html The loops I see there are trivial. Any loop where you have two arrays and you apply an operation OP between elements of the arrays is trivial and actually not very often met in practice. In practice you often have: - Conditional expressions in loop body. - Non-trivial loop exit conditions. - Horizontal operations between elements of the same array. - Array elements more dense than int. (Auto-vectorizers tend to widen elements as per C++ promotion rules.) - Input data provided via pointers that may theoretically overlap. (Auto-vectorizers tend to be pessimistic about data overlap, unless persuaded by non-portable means.) Any of the above is typically poorly handled by auto-vectorizers, if at all. At least, that was my observation when I wrote code that I subsequently had to manually vectorize. PS: I'm sending this to the ML.

1 1

Re: [boost] linux build and version symlinks question
by Peter Dimov 16 Jun '20

16 Jun '20

> Aleksei Nikiforov wrote: > > > Besides just removing those symlinks after installation, what's the > > proper way for disabling creating these additional symlinks when > > building/installing boost using b2? > > I tried `b2 install install-no-version-symlinks=on`, but it had no effect. > So I guess the answer is "none". I suppose the right thing to do is to > reverse the change and reinstate the original behavior to not install > these symlinks on `b2 install`. I'm not quite sure about `b2 stage`, but > it should probably be consistent with `b2 install`, because many packaging > scripts use `stage` instead of `install` for some reason. See https://github.com/boostorg/boost_install/issues/43 and https://github.com/boostorg/boost_install/commit/ea28ed441fb04f2c5839e99e37…. If you see something wrong with these changes please let me know.

2 1

linux build and version symlinks question
by Aleksei Nikiforov 15 Jun '20

15 Jun '20

Hi. I've noticed that some versions ago boost started creating additional symlinks when built for linux. In addition to boost_${library}.so -> boost_${library}.so.A.B.C symlink, two more symlinks are created: boost_${library}.so.A -> boost_${library}.so.A.B.C and boost_${library}.so.A.B -> boost_${library}.so.A.B.C. Additional symlinks started appearing approximately around version 1.70.0. For example, boost 1.67.0 has library libboost_filesystem.so.1.67.0 and a symlink libboost_filesystem.so. Boost 1.73.0 has library libboost_filesystem.so.1.73.0 and 3 symlinks: libboost_filesystem.so, libboost_filesystem.so.1 and libboost_filesystem.so.1.73. My guess is that this change was introduced in following commit by removing install-no-version-symlinks feature for all libraries: https://github.com/boostorg/boost/commit/47ef674f752ad2cfeb581665cbea18ee6f… I couldn't find any mention of such change in changelog or any explanation or description of intention of this change. Did I miss it? Was it an unintentional change? In binary linux distributions, *.so files and header files are usually packed into devel packages, while *.so.* are packed into library packages. In case of boost and those symlinks it can lead to an issue. For example, during upgrade from boost 1.72.0 to boost 1.73.0, while both boost 1.72.0 libraries and 1.73.0 libraries are needed temporarily, boost_${library}.so.1 symlinks from both packages may conflict. These symlinks with same names point to different libraries. It's not an issue for devel packages and *.so symlinks with same names since you don't need two devel packages being installed at same time during upgrade. Besides just removing those symlinks after installation, what's the proper way for disabling creating these additional symlinks when building/installing boost using b2? Kind regards, Aleksei Nikiforov

4 9

[double-ended] where is it?
by degski 15 Jun '20

15 Jun '20

I remember going through this review. It was an active, lively and constructive review. Ever since I've been dying to use this new-fangled vector. The repo is dead, no dev branch being worked on. I am happy to implement this container starting from scratch, using the discussions we've had and the valuable comments as a base. I can give it a try, but it will (by the time it gets out of the sausage machine) be a C++20 lib. If that is not acceptable, then no-can-do. degski 🕔https://mega.nz/C!AlJBkaLI

4 4

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

[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

[review][LEAF] Review period is over
by Michael Caisse 04 Jun '20

04 Jun '20

I apologize for not sending this out earlier. The review period is officially complete. A few people have contacted me about completing reviews that they in the middle of and I will be waiting until after this coming weekend to publish the review results. Thank you to those that joined the conversation and provided a review. michael -- Michael Caisse Ciere Consulting ciere.com

1 0

[review][LEAF] Additional reviews in progress?
by Michael Caisse 03 Jun '20

03 Jun '20

Anybody in the process of producing a review to submit? Please respond here or contact me directly. -- Michael Caisse Ciere Consulting ciere.com

3 3

[review] [text] Text review begins June 11
by Glen Fernandes 03 Jun '20

03 Jun '20

The Boost formal review of Zach Laine's Unicode library, Text, commences on June 11th and concludes June 20th. We welcome the participation of Boost developers and users, and the C++ community. Quote: This library includes three layers: - The string layer, a set of types that constitute "a better std::string" - The Unicode layer, consisting of the Unicode algorithms and data - The text layer, a set of types like the string layer types, but providing transparent Unicode support Code: https://github.com/tzlaine/text Docs: https://tzlaine.github.io/text Text requires C++14 or higher, and supports GCC 5+, Clang 3.6+, and MSVC 2017. Zach initially presented the library at C++Now in 2018. He also intends to standardize a library solution for Unicode based on this work. Talk: https://www.youtube.com/watch?v=944GjKxwMBo Slides: https://tinyurl.com/boost-text-slides Try the library today, and please consider submitting a review, or even contributing to the discussion next week. Glen

1 0

Re: [boost] [review][LEAF] Review of LEAF starts today : May 22 - May 31
by Bjorn Reese 02 Jun '20

02 Jun '20

On 2020-05-22 11:31, Michael Caisse via Boost wrote: > 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). I vote to conditionally accept LEAF into Boost. LEAF provides a new perspective on error propagation that is worth exploring in the real world. The conditions for acceptance are: 1. Provide a lower-level API for error handling which does not necessitate a pattern matching framework. I would prefer an API closer to the variant::index() and std::get<I>() combination that enables you to write the error handling as switch statements. More rationale for this request is given under the design evaluation. > - What is your evaluation of the design? LEAF propagates error objects across multiple function calls by letting the callee store the error payload directly in a stack object, called the error context, at the caller. A pointer to the error context is located in thread-local storage. When there are more error contexts on the call stack, they are daisy chained via pointers in the child error context. This is a sound design, which gives LEAF an efficient way of propagating error payloads then a failure occurs. I like that the returned error_id can be passed through C code. There is runtime overhead in creating and destroying the error contexts even when no failure occurs. Whether or not that overhead is acceptable depends on circumstances. It seems to me that the noexcept performance overhead in the successful case and the failure case are not that different (assuming the error payload is not too heavy), so it may be a good idea to choose LEAF when worst-case performance is more important than average-case performance. The more I experimented with LEAF, the more I wished that there was an error handing API with less syntatic sugar. 1. Single-stepping into a TryBlock is really cumbersome. The developer has to single-step through layers of unfamiliar templated code before reaching their own TryBlock. This interrrupts their flow. Setting a breakpoint in the TryBlock helps but is still cumbersome. 2. Some compilation errors are difficult to interpret. For example, if you accidentally omit a required return statement in one of the try_handle_all handlers, then the compiler reports the start of the try_handle_all statement and some internal LEAF voodoo. If you are experienced with reading templates errors, then you may be able to discover the erroneous handler from the LEAF template parameters in the compiler output. The LEAF handling is reminiscient of a variant visitor, but with the variants we can use index() and std::get<T> in a switch statement instead of visitation. I would like to see something similar for LEAF error contexts. I am undecided about the reliance on thread-local storage. Initially I thought that we could just replace thread-local storage with a home- made lookup table using atomics (which are generally available on OS-less platforms, whereas mutexes etc are not,) but Niall's mention of consteval made me unsure (damn you Niall ;-) However, I do not see this as a show-stopper. The try_handle_all() and try_handle_some() functions have different return values. While I understand the rationale given in the reference documentation, it may still be confusing to users if they change from one to the other. This could possibly be solved by making it more clear in the documentation. The remote_handle_all() name is confusing. I would rename it to nested_handle_all(). > - What is your evaluation of the implementation? The implementation is of high quality, and reasonably readable if you are comfortable with templates. I did not do a proper code review, so the following are random notes. Some classes (leaf::result and the internal optional) uses placement-new and explicit destructor calls. I suggest that you create your own construct_at() and destruct_at() which uses the std counterparts when available, and placement-new / explicit destruction otherwise. This will make the code more readable. std::ostream is entangled into various classes for printing. I would prefer if printing was moved into seperate X_io.hpp files to speed up compilation times when not using them. The LEAF_CONSTEXPR should be renamed to LEAF_CXX14_CONSTEXPR to align with the BOOST_CXX14_CONSTEXPR naming. Also the #if should use '>=' instead of '>'. config.h includes <Windows.h>. This should be replaced with Boost.WinAPI. > - What is your evaluation of the documentation? Overall the documentation is well-presented. The examples reconfigures std::cout to throw exceptions. That obscures the examples because now the reader has to learn LEAF and how std::cout exceptions work at the same time. It would be better to move the std::cout exception stuff into a separate example which is only about std::cout. > - What is your evaluation of the potential usefulness of the library? LEAF presents a unique error handling solution, that may be useful to certain users. I do not expect a huge user base though, as LEAF users mainly are going to be projects with requirements not met by the alternatives. > - Did you try to use the library? With which compiler(s)? Did you > have any problems? I experimented with small examples and found no compiler-related issues. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? About 6 hours. Spent most time trying understanding the design than reviewing the code and documentation. > - Are you knowledgeable about the problem domain? Yes.

6 10

Relevance of platfrom-specific shared_ptr implementations
by Peter Dimov 01 Jun '20

01 Jun '20

Greetings, shared_ptr has a number of platform-specific implementations for its control block, specifically the atomic reference count manipulation: https://github.com/boostorg/smart_ptr/blob/develop/include/boost/smart_ptr/… Those have been accumulated over the years and I'd like to clean them up, remove the unused ones and fold as many of them as possible into a few generic implementations using either std::atomic, GCC atomic intrinsics (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/_005f_005fatomic-Builtins.html) or GCC/intel sync intrinsics (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/_005f_005fsync-Builtins.html) But I have no experience with non-x86 platforms and don't know where boost::shared_ptr is still used and which of the platform-specific implementations are still needed. (Neither do I know on which platforms the atomic and the sync intrinsics actually work, as opposed to just compile and then fail to link.) Any information along these lines is welcome. If you know of a platform where boost::shared_ptr is still used, but which supports none of the "modern" ways to implement atomic ops, please let me know. If you would like some of the plaform-specific files to be retained, please let me know. Thanks in advance.

3 2

[boost-ml] recommended way-of-working on the ml leaks locations data.
by degski 01 Jun '20

01 Jun '20

As email clients report local time, the way we (are supposed to) post results in leaking of one's location (if one would analyze, which is easily possible with the archive), first of relative location, but once you triangulate a few (and make a few assumptions, like Niall Douglas is probably in Ireland), you can work them all out. Maybe I'm the person who finds this unpleasant, but I don't find this ideal. degski -- @systemdeg https://www.instapaper.com <http://instapaper.com> "We value your privacy, click here!" Sod off! - degski

1 0