- Boost - lists.preview.boost.org

Fw: Boost accepted in Google Summer of Code 2021
by Christopher Kormanyos 17 Jan '25

17 Jan '25

----- Forwarded Message ----- From: "boost-users-owner(a)lists.boost.org" <boost-users-owner(a)lists.boost.org>To: "e_float(a)yahoo.com" <e_float(a)yahoo.com>Sent: Wednesday, March 10, 2021 at 07:51:24 PM GMT+1Subject: Re: [boost] Boost accepted in Google Summer of Code 2021 To post messages to the Boost Users mailing list, you will need to subscribe this e-mail address via the Boost mailing list web page at: http://lists.boost.org/mailman/listinfo.cgi/boost-users You will need to take this step even if you intend to post only through GMane or some other news gateway. In this case, you may wish to edit your subscription options to turn off mail delivery. >> We're in again! > Thank you, David! Hi Matt (@mborland) This was, as far as i recall, our last successful timegetting into and finishing some GSoC 2021 projects. We had that whole Corona thing going on and it wasa tough time for everyone. As far as applying as an org, maybe David hassome old material. - Chris_________________________________________Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 2

Adding logical implication to boost
by Ivan Matek 09 Jan '25

09 Jan '25

Hi everyone, there has been a recent proposal to add logical implication to C++ as an operator. github tracking issue <https://github.com/cplusplus/papers/issues/1641> P2971R2 <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2971r2.pdf> For a video description you can see this talk <https://youtu.be/bgyY3x8y4PE?feature=shared&t=1470> by Walter(it is only few minutes, not entire talk). While I agree with concerns mentioned on the issue, i.e. using a *precious *token => on rarely used functionality I do think that implementing a simple function helper is reasonable. Poll in issue shows that this is also likely standardization future. POLL: We agree with adding a function object logical_implication (tentative name, akin logical_and, `logical_or’). SF F N A SA 9 12 3 0 0 As for if it is worthwhile to add this simple logic to boost instead of people just writing their own I will just say I would prefer to have something named in boost instead of people reinventing same thing many times in their projects. I have used it few times in my career, so quite rarely, but again that means I have used it much more often than 80+% of algorithms in <algorithm> header. As for location I presume best place would be Boost.Algorithm although you could say that Boost.Core can be a candidate because it is a basic operation and would benefit from shorter namespace. I would be still inclined against this since I have seen core/util/common become huge in many codebases I have worked in. I have tried to check if this already exists in Boost; all I found was an example in Boost.Hana.

6 7

Forthcoming Decimal Library review (15th Jan)
by John Maddock 08 Jan '25

08 Jan '25

Just a gentle reminder that the review of the decimal number library by Matt Borland and Chris Kormanyos will start NEXT WEDNESDAY 15th Jan. The library is an implementation of IEEE 754 Decimal Floating Point Numbers. Documentation: https://cppalliance.org/decimal/decimal.html Code: https://github.com/cppalliance/decimal/ Motivation: Current C++ floating point types store the significand (often incorrectly referred to as the mantissa) as binary digits. Famously this leads to representation errors: https://0.30000000000000004.com <https://0.30000000000000004.com>. Decimal floating point numbers avoid this issue by storing the significand in base-10 (decimal). The other major difference between binary and decimal floating point types is that the latter allows for multiple representations of the same number. For example 1e5 could also be stored as 0.1e6, 0.01e7, so on and so forth. These are referred to as cohorts which binary does not have as there is only one way to represent each number in binary floating point. Use Cases: The use case for Decimal Floating Point numbers is where rounding errors are significantly impactful such as finance. In applications where integer or fixed-point arithmetic are used to combat this issue Decimal Floating Point numbers can provide a significantly greater range of values. For example, while a fixed-point representation that allocates 8 decimal digits and 2 decimal places can represent the numbers 123456.78, 8765.43, 123.00, and so on, a floating-point representation with 8 decimal digits could also represent 1.2345678, 1234567.8, 0.000012345678, 12345678000000000, and so on. I believe Matt has some minor doc updates to push between now and next week, but other than that the library is good to review (but hold your fire until we start next week unless you're away etc). Best, John.

1 0

Invalid sha256 for boost_1_87_0.tar.bz2 archive
by Samuel DEBIONNE 07 Jan '25

07 Jan '25

Dear all, In the conda forge CI (that builds the boost packages), I noticed that some jobs are failing due to a difference between the advertised and computed sha256 checksum. The json file at https://archives.boost.io/release/1.87.0/source/boost_1_87_0.tar.bz2.json has af57be25cb4c4f4b413ed692fe378affb4352ea50fbe294a11ef548f4d527d89 While sha256sum of https://boostorg.jfrog.io/artifactory/main/release/1.87.0/source/boost_1_87… gives 79e6d3f986444e5a80afbeccdaf2d1c1cf964baa8d766d20859d653a16c39848 Has the archive been updated and not the sidecar json file? Thank you, Samuel

2 2

Your Boost Talk at CppCon?
by Vinnie Falco 02 Jan '25

02 Jan '25

Hi everyone. I think it would be nice to have several talks about Boost for the 2025 CppCon program. We need volunteers who are able to attend and give a talk. If you are interested please email me at vinnie.falco(a)gmail.com to indicate your intent and propose a subject for the talk. There are some resources available to help volunteers get their abstract prepared for submission, to improve the quality of the proposal, ensuring a greater likelihood of the talk being accepted. Getting a Boost talk accepted has been hit or miss in recent years and I would like to change that. If we can get enough volunteers involved much earlier in the process (say, this month) then we have time to assemble a strong "Boost track" with high quality abstracts. This can incentivize the conference to make Boost talks an enduring feature of its programs going forward. If you have questions or comments about Boost talks at CppCon or other conferences, a discussion here is also welcomed. Thanks!

1 0

Re: [boost] announcing boost.async
by microcai 01 Jan '25

01 Jan '25

Klemens Morgenstern via Boost <boost(a)lists.boost.org> 于2023年3月17日周五 23:22写道： > Hi, > > I've been working on a C++20 coroutine library, called `async`, > which is meant to be for C++ what asyncio is for python or generic > async/await is for javascript. > It's meant to be a framework for single threaded coroutine applications. > > It provides coroutine types, such as promises, tasks and generators to > generators are useless for real word coroutine usage. > model async operations, > channels for inter-coroutine communication and functions > like select, gather & join to wait or combine multiple awaitables. > > It's asio-based, i.e. uses asio::io_context as its event-loop and can > co_await any asio operation. > > As this is a very complex domain, I really would be happy to have some > users. > This will help me to improve documentation & come up with more > example ideas. > > Docs: https://klemens.dev/async > Repo: https://github.com/klemens-morgenstern/async > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

[boost.context] questions about Lazy Float Point State Preservation
by microcai 01 Jan '25

01 Jan '25

Does jum_fcontext do lazy state preservation on FPU? most of the time, coroutine is executing async IO code rather than cpu intensive code. Mostly, IO code does not use floating point. but no preserving FPU state is error prone. Does fcontext employ "lazy state preservation on fpu registers"?

1 0

Adding optional<T&> find like method to associative containers in boost.
by Ivan Matek 28 Dec '24

28 Dec '24

Hi everybody, I presume somebody thought of this before but for some reason it never happened, but just in case it was never discussed I wonder if people here believe adding an nicer version of find(with different name obviously) to associative containers in boost would be beneficial? Since boost::optional allows references this would work. I presume naming is what most people will have strong feeling about. I personally prefer ofind/oat since I love short names, Barry suggested different names in his blog <https://brevzin.github.io/c++/2023/05/23/map-api/>, e.g. try_at. boost::optional did not get all the updates C++23 std::optional got, e.g. transform that make this usage compose nicely, but those could be added to boost::optional.

13 80

Formal review request for Hash2
by Peter Dimov 23 Dec '24

23 Dec '24

I'd like to request a formal review for the Hash2 library https://github.com/pdimov/hash2 https://pdimov.github.io/hash2/ (by Christian Mazakas and myself.) The library implements an extensible framework for implementing hashing algorithms that can support user-defined types. Its structure is largely based on the paper "Types don’t know #" by Howard Hinnant, Vinnie Falco and John Bytheway. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3980.html We're looking for a review manager. Comments and questions are welcome; you don't need to wait for the review.

14 75

[hash2] Review Report
by Matt Borland 21 Dec '24

21 Dec '24

Dear all, Again, thank you to those who participated in the review of `Hash2` by Peter Dimov and Christian Mazakas from 7 to 15 December 2024. Bottom line up front: The library is ACCEPTED. By and large, the discussion around the library was positive, with reviewers appreciating that it implements the "Types don't know #" proposal. I think some discussion was perhaps too narrowly focused on providing hash algorithms, as that is not the over-arching goal of the library. Below is a summary of the main discussion points and recommendations from both reviewers and me. Discussion and Recommendations: 1) Support for `std::span`. Based on the discussion, it seems like the use of `std::span` has moved from theoretical to being quite popular. Adding an API for span would in principle be OK behind the requisite feature test macros, but it will add to the conceptual requirements which I'm not convinced is beneficial. Unless Peter and Christian intend to move to C++20, and they don't, I think it would be unreasonable at this time to require spans behind macros in the implementation to allow warning-free builds with Clang's `-Wunsafe-buffer-usage` and whatever memory safety profiles turn out to be. If this library was targeting C++20, or intended to be certified by a standards organization, this would be an entirely different conversation. 2) C++ language standard requirement. As I kind of expected, there was limited support for keeping the library at C++11. The authors should feel free to use C++14 and drop support for any non-conforming compilers before initial release. 3) Documentation. Peter Turcan provided a great deal of feedback on the documentation which I expect the authors to handle. There were also quite a few calls to re-arrange the documentation to put working examples and pitfalls discussed during review first, and details of concepts later. The single vs. multi-page documentation debate will never have a clear winner, so I defer to doc writer's preference on that one. The authors have a pretty good sense of the edits they need to make, so I won't belabor the point. 4) Security. Secure construction was included in the conditional acceptance criteria of two reviews - for example, default construction and allowing too-short keys in SipHash were considered harmful. There were also concerns that the algorithms provided would be considered cryptographically secure. Since the library does not intend to be a cryptographic provider (as that is not the real point of the library), I think an annotation at the top of the docs stating as much should be added. 5) Relationship to `ContainerHash`. Several reviewers noted that since there is no explicit Hash1, the relationship with `ContainerHash` should be explained. Peter currently maintains `ContainerHash`, so I think it would be useful to add similar documentation there as well. This could help avoid the situation we have now where `MP11` fully replaces the functionality of `MPL`, but that's not obvious to the casual outside observer. 6) The concept of HashAlgorithm. There was much discussion around the concept of HashAlgorithm and how it deviates from existing practice. If Peter and Christian don't want to be the sole providers of hash algorithms for their library, they need to provide: - A way to use existing implementations and/or examples in the documentation (this was part of the acceptance criteria for all but one conditional acceptance). This can be accomplished by adding Guidance and an example of an adapter. - An FAQ section addressing questions like "Why does the library impose additional requirements such as result extension on hash algorithms which go beyond the cryptographic specifications in corresponding RFCs?" Boost.Multiprecision already implements this approach to allow unknown arithmetic backends to be used. Final Verdict: I ACCEPT the library. The library was clearly well designed, and the authors provided clear justification for implementation decisions when questioned (e.g., `tag_invoke` for functions as customization points). Peter and Christian are both responsive enough that I expect they will address the above list without needing the forcing function of a conditional accept followed by a review in the future to ensure completeness. In fact Christian already showed me a draft of an OpenSSL adaptor. If this library was coming from an outsider, my opinion would be different. For transparency the final tally of reviews received was ACCEPT: 9, REJECT: 3, CONDITIONAL ACCEPT: 5. Thanks again to all that participated and congratulations to Peter and Christian. Happy Holidays, Matt

3 2