- Boost - lists.boost.org

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

[LEAF] Loss of error_id
by Bjorn Reese 26 May '20

26 May '20

In the noexcept case, what happens in the Error-Handling function if the error_id generated by the Error-Reporting function is lost by the intermediate functions?

2 4

Request for 1.73 patch release
by Richard Hodges 25 May '20

25 May '20

Dear all, Just prior to the release of boost 1.73, some changes appeared in Asio which use the new c++20 concepts (and concepts-ts) features where available. These changes have introduced breakage in Beast in compilers where concepts are enabled. Examples are gcc=10 and clang10 with -std=c++20. I have pushed a fix to beast/develop to address this, but sadly we only became aware of the problem after the release of boost 1.73.0 I suspect the cause here is a combination of my relatively new appointment as a Beast maintainer and the ground-breaking event which I am sure c++20 will prove to be. I welcome any guidance on preparing or initiating a patch release as I lack the Arcane Knowledge required. For information, here is a link to the commit which fixes the problem: https://github.com/boostorg/beast/pull/1927 And some bug reports that alerted us that somethig was wrong: https://github.com/boostorg/beast/issues/1916 https://github.com/boostorg/beast/issues/1925 -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

6 13