- Boost - lists.preview.boost.org

[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

Re: [boost] [Boost-users] [review][LEAF] Review of LEAF
by Niall Douglas 01 Jun '20

01 Jun '20

On 01/06/2020 12:51, degski via Boost-users wrote: > Is there scope for merging LEAF and Outcome as it seems from (very > detailed discussions) that they only partially overlap? My own opinion: 1. You may remember that Emil was one of two people who voted to reject Outcome back during its review, as he felt that it was the wrong design. His comments on what would be better back then map well onto what he has presented in LEAF. I find that very reasonable: (i) he thought he could do better (ii) he went ahead and did better in his opinion (iii) he is presenting now what he thinks is better, and is asking Boost for its opinion on whether he improved things or not. 2. There is long established precedence for Boost containing multiple libraries that approach a problem from multiple perspectives e.g. we currently have three error handling libraries, four maths libraries etc. If LEAF were accepted, you'd now have four instead of three error handling libraries. And that seems to me just fine, and not out of precedence. 3. I specifically and deliberately chose to not design Outcome like LEAF. I thought then, and I still do, that Outcome ought to be great at all the things no other solution is great at. I think I succeeded on that. As I already stated in my own review of LEAF, I personally think that there is already a perfectly good implementation of LEAF shipping in any C++ compiler of the past twenty years. I don't, personally speaking, see the value add for choosing LEAF over C++ exceptions except to tick some box called "C++ exceptions globally disabled compatible". > I don't think > that 'we' should keep on adding distinct libraries that partially > overlap, Existing libraries should be expanded instead, and > deduplication should be done in a coordinated way (in this case between > LEAF and Outcome). Something has to be done to stop exponential growth > of Boost while maintaining flexibility to add code at will. The best way to stop exponential growth of Boost, if that is desirable, is to start culling libraries that aren't maintained nor useful. Or at least publish a documented list of libraries that new code ought to not use. > As C++ already has exceptions (and will have exceptions light in the > future), the use-case you presented to use LEAF surgically with C-api's > seems convincing (it presents a better case than the case of generically > re-working an exception system that works, is fundamental to C++ and is > promised to be improved in the future, i.e. it's the safest bet. Any > library is secured till maintenance ceases, the language/STL > (exceptions, exceptions light) is a pdf-file (i.e. future proof by default). The current formulation of lightweight exceptions before WG21 is literally Experimental Outcome in language form. Same proposed error object, std::error. It is currently expected that both value-based and type-based exceptions would exist in future C++, in order to retain backwards compatibility, as the semantics between the two are not currently believed possible to be made exactly one-one. Experimental Outcome works fine in C code, same as how the most recent proposal for lightweight exceptions also supports C. Niall

2 3

Re: [boost] Relevance of platfrom-specific shared_ptr implementations
by Bjorn Reese 31 May '20

31 May '20

On 2020-05-31 17:18, Peter Dimov via Boost wrote: > 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) How about a fall-back to Boost.Atomic?

1 0

Re: [boost] boost reviewLEAF Review of LEAF starts today : May 22 - May 31
by Jess 29 May '20

29 May '20

Hey, big boy! My boyfriend is visiting his parents for a week and I want to get laid. You actually live just nearby. Do you want to see some of my cheeky pictures? It is in my profile On this site | | | | Online Hookup | | | Kisses, Jess

3 2

[review][LEAF] Review period ending soon - May 31
by Michael Caisse 28 May '20

28 May '20

I'd like to encourage each of you to review Emil's error handling library. We often focus on design or implementation based reviews, and I encourage those but what I would really like to see are more user based reviews. Grab the library and docs and play with it a bit. What works well? What can be improved? As a reminder, some of LEAF's features include: * arbitrary error types * header-only * no dependencies * use without exceptions * use with exceptions * no dynamic memory alloc You can find the documentation here: <https://zajo.github.io/leaf/> and the library source here: <https://github.com/zajo/leaf/tree/review> Thanks! michael -- Michael Caisse Ciere Consulting ciere.com

1 0

[epochs] Proposal for an epoch-based organization of Boost libraries
by Joaquin M López Muñoz 28 May '20

28 May '20

Hi, Prompted by general feelings about Boost perceived lack of modernization and internal "bloat", and after an explicit survey on what users dislike about Boost [1], I decided to try and write a more or less fleshed out proposal for an epoch-based organization of Boost libraries. I've extensively tested and refined the proposal during discussions on Reddit and the Boost Slack channel, and I feel this is now ready for presentation at the mailing list: https://github.com/joaquintides/boost_epoch/blob/master/README.md I hope the proposal can start a productive conversation. Looking forward to your feedback. Best, Joaquín M López Muñoz [1]: https://www.reddit.com/r/cpp/comments/gfowpq/why_you_dont_use_boost/

13 42

Optional library
by anshu khare 27 May '20

27 May '20

Hi mentors I was going through the optional library of boost. I was facing some problem in understanding the code base. In lines from 94 to 97 in optional.hpp, the code is as follows: struct in_place_init_if_t { Struct init_tag{}; explicit in_place_init_if_t(init_tag) {} //not able to understand this line }; I understand that we are creating a structure in_place_init_if_t and inside that we are creating another structure init_tag and then we are calling the constructor of in_place_init_if_t. But I am not able to understand that what does it the constructor do when we pass init_tag as an argument to it. Is it same as we are creating a structure Car and then creating another structure wheels inside it and passing wheels as an argument to the constructor of car as follows: struct car { Struct wheels{}; explicit car(wheels) {} //not able to understand this line }; Could you please tell what is the significance of passing wheels as an argument in this counter example?

2 1