- Boost - lists.boost.org

Changelog for 1.76 is outdated
by Antony Polukhin 28 Mar '21

28 Mar '21

Hi, The https://www.boost.org/users/history/version_1_76_0.html seems quite outdated. Please update Thanks in advance!

2 4

Re: [boost] Boost Digest, Vol 6566, Issue 1
by shady mohamed 28 Mar '21

28 Mar '21

I want to talk with engineer david bellot and engineer cem bassoy Thanks في الجمعة، ٢٦ مارس، ٢٠٢١ ١٢:٢٣ م <boost-request(a)lists.boost.org> كتب: > Send Boost mailing list submissions to > boost(a)lists.boost.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.boost.org/mailman/listinfo.cgi/boost > or, via email, send a message with subject or body 'help' to > boost-request(a)lists.boost.org > > You can reach the person managing the list at > boost-owner(a)lists.boost.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Boost digest..." > > > The boost archives may be found at: http://lists.boost.org/Archives/boost/ > > > Today's Topics: > > 1. Re: [Boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 (Andrzej Krzemienski) > 2. Re: [release] 1.76.0 post-beta merges (Niall Douglas) > 3. Re: [Boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 (Peter Dimov) > 4. Re: [release] 1.76.0 post-beta merges (Marshall Clow) > 5. Re: [release] 1.76.0 post-beta merges (Niall Douglas) > 6. Re: [release] 1.76.0 post-beta merges (Glen Fernandes) > 7. Re: [Lambda2] Review starts Monday March 22, 2021 to March > 31, 2021 (Julien Blanc) > 8. Re: [Lambda2] Review starts Monday March 22, 2021 to March > 31, 2021 (Andrzej Krzemienski) > 9. Re: [Lambda2] Review starts Monday March 22, 2021 to March > 31, 2021 (Julien Blanc) > 10. Re: [Boost] [Describe] Summary Review Summary (Emil Dotchevski) > 11. Re: [Lambda2] Review starts Monday March 22, 2021 to March > 31, 2021 (Mathias Gaunard) > 12. Re: [Boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 (Mathias Gaunard) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 25 Mar 2021 14:54:17 +0100 > From: Andrzej Krzemienski <akrzemi1(a)gmail.com> > To: Boost mailing list <boost(a)lists.boost.org> > Cc: Peter Dimov <pdimov(a)gmail.com> > Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22, > 2021 to March 31, 2021 > Message-ID: > <CAOenAXhsJ1yCRRBYgJuPh8xws5MMVCks7p6GvfmBG+= > 28QDNPg(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > pon., 22 mar 2021 o 16:44 Peter Dimov via Boost <boost(a)lists.boost.org> > napisa?(a): > > > Edward Diener wrote: > > > My first reaction, after quickly looking at the submission, is what > does > > this > > > library offer that the original lambda library, which appears to have a > > much > > > larger amount of functionality than this lambda2 library, not offer ? > > Also there > > > is the Phoenix library, which also offers an even greater amount of > > function > > > object and lambda-like functionality, of which the review manager is > the > > main > > > author I believe. > > > > Purely from a user perspective, what this library offers is being a > > lightweight, > > single header dependency, and... > > > > > Is it basically so that the programmer can easily interface with > > > the std::bind/std::function classes with the lambda2 placeholders, > > whereas the > > > C++03 libraries don't have this possibility wit their placeholders ? > > > > ... indeed, a way to port boost::bind code that uses its operators to > > std::bind, > > something that comes up from time to time as projects are modernized. > > > > From a different perspective, another goal of the submission is to gather > > experience and provide a tested and widely available implementation for > an > > eventual proposal to add this functionality to the standard. (Better late > > than > > never.) > > > > My opinion so far is that there is not enough motivation to warrant the > addition of this library into Boost. > > First, the design goals, or the purpose, of the library is not clearly > defined. > > Is the goal that tandem std::bind + Boost.Lambda2 should be a replacement > over boost::bind and Boost.Lambda? If so, in the current form of the > library the goal will not be satisfied, because current Boost.Lambda offers > quite more things. Just look at the motivating examples of Boost.Lambda: > https://www.boost.org/doc/libs/1_75_0/doc/html/lambda/using_library.html > In particular, the usage of assignment or function constant(). > Boost.Lambda2 will not work as a drop-in replacement for Boost.Lambda. > > For a moment I thought that the goal is to have a cooler syntax for the > current standard arithmetic function objects, such as std::plus, > std::multiplies. But the advantage is dubious. You gain a few characters, > but you pay the cost of > * employing a different library > * messy error messages > * no debugger support > > The suggestion that we would enable constructs like > `std::bind(&Employee::name, e1) < std::bind(&Employee::name, e2)`also > doesn't seem like a good motivation. std::bind only works well when it is > used for binding arguments to functions. Overusing it for implementing > lambdas made sense in C++03, because there was no other way. Now with > generic lambdas it can only be considered a bad (or at least controversial) > practice. > > I am far from imposing my programming style on others. But promoting a > programming style like this through the inclusion into Boost seems too > much. My vision of Boost is that it should support certain programming > styles that are considered good, but not any programming style. > > Regarding the implementation, on the other hand, it is as elegant as a > library implementation could ever be. It is extremely short! (78 lines, > including whitespace, header guards, and copyright notice). > > Regards, > &rzej; > > > ------------------------------ > > Message: 2 > Date: Thu, 25 Mar 2021 15:06:02 +0000 > From: Niall Douglas <s_sourceforge(a)nedprod.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] [release] 1.76.0 post-beta merges > Message-ID: <6efb04af-9f26-4d04-a187-8bc08369caf3(a)nedprod.com> > Content-Type: text/plain; charset=utf-8 > > On 16/03/2021 20:24, Marshall Clow via Boost wrote: > > The master branch is is now open for post-beta merges, but only as > described in the Post-Beta Merge Policy. > > See < > https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy> > > I would like to fix https://github.com/ned14/outcome/issues/249 by > improving the logic at > > https://github.com/ned14/outcome/blob/develop/include/outcome/convert.hpp#L… > please. > > Niall > > > ------------------------------ > > Message: 3 > Date: Thu, 25 Mar 2021 17:24:15 +0200 > From: "Peter Dimov" <pdimov(a)gmail.com> > To: "'Andrzej Krzemienski'" <akrzemi1(a)gmail.com>, "'Boost mailing > list'" <boost(a)lists.boost.org> > Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22, > 2021 to March 31, 2021 > Message-ID: <131601d7218a$eb1033b0$c1309b10$(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > Andrzej Krzemienski wrote: > > First, the design goals, or the purpose, of the library is not clearly > defined. > > The goals of the library are > > - Give people the choice of using an abbreviated lambda syntax that is able > to express simple operations in fewer characters; > - Bring std::bind to parity with boost::bind feature-wise so that porting > is > easier; > - Prepare a proposal to extend the standard with these same additions by > gathering experience in Boost first. > > > Is the goal that tandem std::bind + Boost.Lambda2 should be a replacement > > over boost::bind and Boost.Lambda? If so, in the current form of the > library > > the goal will not be satisfied, because current Boost.Lambda offers > quite more > > things. > > This doesn't make it useless. When porting "operator-enhanced" boost::bind, > or Boost.Lambda, code, you need to go over all the uses and change them > into language lambdas. This is routine mechanical work that as a result is > highly error-prone and without good test coverage, mistakes can easily pass > review because of the repetitive nature of the diff. It's much better if > you > could port at least some of the uses without making changes beyond > replacing > boost:: with std::, and adding/changing the using directive. > > It's not necessary to be able to port _all_ uses without any changes; a > portion > is enough to reduce the error rate significantly. > > And if you're going to ask what's the point of porting from one Boost > library > to another, the difference is that it's much easier to "vendor" a single > short > header. > > > For a moment I thought that the goal is to have a cooler syntax for the > current > > standard arithmetic function objects, such as std::plus, > std::multiplies. But the > > advantage is dubious. You gain a few characters, but you pay the cost of > > * employing a different library > > * messy error messages > > * no debugger support > > This could be true, but it has nothing to do with the library lacking > clarity of > purpose. > > > The suggestion that we would enable constructs like > > `std::bind(&Employee::name, e1) < std::bind(&Employee::name, e2)`also > > doesn't seem like a good motivation. > > As explained, this is only an issue when porting boost::bind code using > these constructs. You obviously aren't going to use this in new code > because > the equivalent language lambda is shorter (not by much) and clearer. > > > > ------------------------------ > > Message: 4 > Date: Thu, 25 Mar 2021 08:45:22 -0700 > From: Marshall Clow <mclow.lists(a)gmail.com> > To: Boost Developers List <boost(a)lists.boost.org> > Subject: Re: [boost] [release] 1.76.0 post-beta merges > Message-ID: <0EAF569D-A080-4217-BC77-D7CE4057EC0A(a)gmail.com> > Content-Type: text/plain; charset=utf-8 > > On Mar 25, 2021, at 8:06 AM, Niall Douglas via Boost < > boost(a)lists.boost.org> wrote: > > > > On 16/03/2021 20:24, Marshall Clow via Boost wrote: > >> The master branch is is now open for post-beta merges, but only as > described in the Post-Beta Merge Policy. > >> See < > https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy> > > > > I would like to fix https://github.com/ned14/outcome/issues/249 by > > improving the logic at > > > https://github.com/ned14/outcome/blob/develop/include/outcome/convert.hpp#L… > > please. > > Do you have a commit that fixes this? > > ? Marshall > > > > > ------------------------------ > > Message: 5 > Date: Thu, 25 Mar 2021 16:04:17 +0000 > From: Niall Douglas <s_sourceforge(a)nedprod.com> > To: Boost Developers List <boost(a)lists.boost.org> > Subject: Re: [boost] [release] 1.76.0 post-beta merges > Message-ID: <2dc9222a-592a-6b85-c76b-d62ef55611b3(a)nedprod.com> > Content-Type: text/plain; charset=utf-8 > > On 25/03/2021 15:45, Marshall Clow wrote: > > On Mar 25, 2021, at 8:06 AM, Niall Douglas via Boost < > boost(a)lists.boost.org> wrote: > >> > >> On 16/03/2021 20:24, Marshall Clow via Boost wrote: > >>> The master branch is is now open for post-beta merges, but only as > described in the Post-Beta Merge Policy. > >>> See < > https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy> > >> > >> I would like to fix https://github.com/ned14/outcome/issues/249 by > >> improving the logic at > >> > https://github.com/ned14/outcome/blob/develop/include/outcome/convert.hpp#L… > >> please. > > > > Do you have a commit that fixes this? > > The change is trivial. Current: > > ```c++ > #if !defined(_MSC_VER) && !defined(__clang__) && (__GNUC__ < 9 || > __cpp_concepts < 201907L) > #define OUTCOME_GCC6_CONCEPT_BOOL bool > #else > #define OUTCOME_GCC6_CONCEPT_BOOL > #endif > ``` > > To be replaced with: > > ```c++ > #if (defined(_MSC_VER) || defined(__clang__) || (defined(__GNUC__) && > __cpp_concepts >= 201707) || OUTCOME_FORCE_STD_CXX_CONCEPTS) && > !OUTCOME_FORCE_LEGACY_GCC_CXX_CONCEPTS > #define OUTCOME_GCC6_CONCEPT_BOOL > #else > #define OUTCOME_GCC6_CONCEPT_BOOL bool > #endif > ``` > > To explain, GCC expects bool with concept, or not, in varying > configuration combinations which have evolved over GCC versions, > including apparently point releases, which is deeply unhelpful. This has > led to repeated bug reports for not just Outcome, but also for ASIO and > many other C++ projects. > > If this above fix doesn't permanently shut this constant source of bug > reports, I'll be permanently disabling legacy GCC concepts support in > Outcome. I couldn't be arsed with supporting how unpredictably broken > GCC is with this. > > Niall > > > ------------------------------ > > Message: 6 > Date: Thu, 25 Mar 2021 12:12:03 -0400 > From: Glen Fernandes <glen.fernandes(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] [release] 1.76.0 post-beta merges > Message-ID: > <CAHVPgznFdSVYJ9gR8LzP7qQV7w5+fcjBvKq95ReUKkFR-ct= > Qg(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Thu, Mar 25, 2021 at 12:04 PM Niall Douglas via Boost > <boost(a)lists.boost.org> wrote: > > > > On 25/03/2021 15:45, Marshall Clow wrote: > > > On Mar 25, 2021, at 8:06 AM, Niall Douglas via Boost < > boost(a)lists.boost.org> wrote: > > >> > > >> I would like to fix https://github.com/ned14/outcome/issues/249 by > > >> improving the logic at > > >> > https://github.com/ned14/outcome/blob/develop/include/outcome/convert.hpp#L… > > >> please. > > > > > > Do you have a commit that fixes this? > > > > The change is trivial. Current: > > If you're asking for permission to merge to master now, you should > have a commit on outcome's develop branch that we can look at. You are > free to commit to develop at any time. Only master is locked. > > Glen > > > ------------------------------ > > Message: 7 > Date: Thu, 25 Mar 2021 19:10:33 +0100 > From: Julien Blanc <julien.blanc(a)tgcm.eu> > To: boost(a)lists.boost.org > Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 > Message-ID: <2773cbf43ec651fdf2b3a3262c8476d814047eb0.camel(a)tgcm.eu> > Content-Type: text/plain; charset="UTF-8" > > Le lundi 22 mars 2021 ? 10:35 +0800, Joel de Guzman via Boost a ?crit?: > > The Boost formal review of the Lambda2, authored by Peter Dimov, > > starts Monday, March 22, 2021 to March 31, 2021 (inclusive). > > Here's my small review of the lambda 2 library. > > TLDR: ACCEPT > > > ?? - What is your evaluation of the design? > > ?? - What is your evaluation of the implementation? > > The library is a really small piece of code, like other reviewers > already noticed. During my tests, i came across two things that could > be improved: > * the internal macro BOOST_LAMBDA2_UNARY_LAMBDA and > BOOST_LAMBDA2_BINARY_LAMBDA #undefed at the end of the file. While i > undestand that it is an internal macro, it could be exposed to the user > to allow implementation for other operators > * that macro hardcode the std prefix, it could be part of its call, ie: > > BOOST_LAMBDA2_BINARY_LAMBDA(+, std::plus) // instead of > BOOST_LAMBDA2_BINARY_LAMBDA(+, plus) > > This would allow the user of the library to get the building blocks to > customize other operators to its needs (I have implemented unary > operator* easily that way). > > > ?? - What is your evaluation of the documentation? > > The documentation is really good at telling what the library does, is > clean, nice looking. > > > ?? - What is your evaluation of the potential usefulness of the > > library? > > At first glance, i was thinking that this was the kind of library that > i would never use. I find the count_if examples in the documentation > not really convincing. > > Then, it happened that i made some experiments with c++20 ranges. And i > find that, in this context, shortening the lambdas gives a real benefit > to the code. It basically started from the need to feed a function that > was needing a list of non owner references to T from a > vector<unique_ptr<T>>. As I was not satisfied with the solution, I > checked whether c++20 ranges could provide an elegant solution to this. > Something like > > f(std::views::transform(vec, deref)); > > implementing deref is easy. Then, out of curiosity, i checked if i > could use Peter's library to be able to write something like: > > f(std::views::transform(vec, *_1)); > > I actually find that this way of writing is more natural than the > former. > > So, i wrote : > > namespace std // BAD, don't do that > { > template<typename T = void> > struct deref > { > decltype(auto) operator()(T& v) { return *v; } > }; > template<> > struct deref<void> > { > template<typename T> > decltype(auto) operator()(T& v) { return *v; } > }; > } > > BOOST_LAMBDA2_UNARY_LAMBDA(*, deref); > > modified Peter's library to remove the #undef, and voila, it just > works. > > I see a lot of potential for the short writing form for lambdas, in > conjunction with the ranges library. I find convenient to write: > > f(std::views::transform(vec, _1 + 1)) // convert from 0-based to 1- > based index > > > ?? - Did you try to use the library? With which compiler(s)? Did you > > ???? have any problems? > > No specific issue encountered, with gcc-10. Error messages are a bit > cryptic. > > > ?? - How much effort did you put into your evaluation? A glance? A > > quick > > ???? reading? In-depth study? > > A few hours playing with the library. > > > ?? - Are you knowledgeable about the problem domain? > > Not at all. > > My feeling is the following. At first glance, i was wondering what was > the use case the library addressed. After playing a bit with it, i'm > now convinced that people will want to use it, and, like me, will > probably want to expand it to fit their need. I was not suspecting that > it was possible to write code that way. I suspect most developers are > not either. Now that it is known it's possible, people will come up > with their own, probably inferior, solution. Having such a feature in > boost would at least provide everyone with a correct implementation of > it. Because people will want to write code like this, and i believe, > especially with ranges. > > Thanks to Peter for writing this library, and proposing it to boost. > Reviewing it has been very interesting and instructive. > > Regards, > > Julien > > > > ------------------------------ > > Message: 8 > Date: Fri, 26 Mar 2021 05:54:36 +0100 > From: Andrzej Krzemienski <akrzemi1(a)gmail.com> > To: Boost mailing list <boost(a)lists.boost.org> > Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 > Message-ID: > <CAOenAXgEDx= > kmKY5gVdST-oAeipoa2oG2s5j_y0brxs34r7ojw(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > czw., 25 mar 2021 o 19:11 Julien Blanc via Boost <boost(a)lists.boost.org> > napisa?(a): > > > Le lundi 22 mars 2021 ? 10:35 +0800, Joel de Guzman via Boost a ?crit : > > > The Boost formal review of the Lambda2, authored by Peter Dimov, > > > starts Monday, March 22, 2021 to March 31, 2021 (inclusive). > > > > Here's my small review of the lambda 2 library. > > > > TLDR: ACCEPT > > > > > - What is your evaluation of the design? > > > - What is your evaluation of the implementation? > > > > The library is a really small piece of code, like other reviewers > > already noticed. During my tests, i came across two things that could > > be improved: > > * the internal macro BOOST_LAMBDA2_UNARY_LAMBDA and > > BOOST_LAMBDA2_BINARY_LAMBDA #undefed at the end of the file. While i > > undestand that it is an internal macro, it could be exposed to the user > > to allow implementation for other operators > > * that macro hardcode the std prefix, it could be part of its call, ie: > > > > BOOST_LAMBDA2_BINARY_LAMBDA(+, std::plus) // instead of > > BOOST_LAMBDA2_BINARY_LAMBDA(+, plus) > > > > This would allow the user of the library to get the building blocks to > > customize other operators to its needs (I have implemented unary > > operator* easily that way). > > > > Is it not just that the library is missing some operators? If Boost.Lambda2 > overloaded all overloadable operators there would be no point in users > doing it. > > > > > - What is your evaluation of the documentation? > > > > The documentation is really good at telling what the library does, is > > clean, nice looking. > > > > > - What is your evaluation of the potential usefulness of the > > > library? > > > > At first glance, i was thinking that this was the kind of library that > > i would never use. I find the count_if examples in the documentation > > not really convincing. > > > > Then, it happened that i made some experiments with c++20 ranges. And i > > find that, in this context, shortening the lambdas gives a real benefit > > to the code. It basically started from the need to feed a function that > > was needing a list of non owner references to T from a > > vector<unique_ptr<T>>. As I was not satisfied with the solution, I > > checked whether c++20 ranges could provide an elegant solution to this. > > Something like > > > > f(std::views::transform(vec, deref)); > > > > implementing deref is easy. Then, out of curiosity, i checked if i > > could use Peter's library to be able to write something like: > > > > f(std::views::transform(vec, *_1)); > > > > I actually find that this way of writing is more natural than the > > former. > > > > This is an interesting observation. In my experience, storing collections > of ints is a rare case in production code (it is frequent in tests, > tutorials, books, presentations), maybe this is why arithmetic operators do > not appear as something practical. However pointers (including smart ones) > to user-defined types is something that I see a lot. The following als > looks as something I would see often in the code: > > assert(std::ranges::all_of(records, _1 != nullptr)); > > Regards, > &rzej; > > > > So, i wrote : > > > > namespace std // BAD, don't do that > > { > > template<typename T = void> > > struct deref > > { > > decltype(auto) operator()(T& v) { return *v; } > > }; > > template<> > > struct deref<void> > > { > > template<typename T> > > decltype(auto) operator()(T& v) { return *v; } > > }; > > } > > > > BOOST_LAMBDA2_UNARY_LAMBDA(*, deref); > > > > modified Peter's library to remove the #undef, and voila, it just > > works. > > > > I see a lot of potential for the short writing form for lambdas, in > > conjunction with the ranges library. I find convenient to write: > > > > f(std::views::transform(vec, _1 + 1)) // convert from 0-based to 1- > > based index > > > > > - Did you try to use the library? With which compiler(s)? Did you > > > have any problems? > > > > No specific issue encountered, with gcc-10. Error messages are a bit > > cryptic. > > > > > - How much effort did you put into your evaluation? A glance? A > > > quick > > > reading? In-depth study? > > > > A few hours playing with the library. > > > > > - Are you knowledgeable about the problem domain? > > > > Not at all. > > > > My feeling is the following. At first glance, i was wondering what was > > the use case the library addressed. After playing a bit with it, i'm > > now convinced that people will want to use it, and, like me, will > > probably want to expand it to fit their need. I was not suspecting that > > it was possible to write code that way. I suspect most developers are > > not either. Now that it is known it's possible, people will come up > > with their own, probably inferior, solution. Having such a feature in > > boost would at least provide everyone with a correct implementation of > > it. Because people will want to write code like this, and i believe, > > especially with ranges. > > > > Thanks to Peter for writing this library, and proposing it to boost. > > Reviewing it has been very interesting and instructive. > > > > Regards, > > > > Julien > > > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > > ------------------------------ > > Message: 9 > Date: Fri, 26 Mar 2021 07:44:43 +0100 > From: Julien Blanc <julien.blanc(a)tgcm.eu> > To: boost(a)lists.boost.org > Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 > Message-ID: <54d581dd2987773250b0f822393ea819a03297bc.camel(a)tgcm.eu> > Content-Type: text/plain; charset="UTF-8" > > Le vendredi 26 mars 2021 ? 05:54 +0100, Andrzej Krzemienski via Boost a > ?crit?: > > > This would allow the user of the library to get the building blocks > > > to > > > customize other operators to its needs (I have implemented unary > > > operator* easily that way). > > > > > > > Is it not just that the library is missing some operators? If > > Boost.Lambda2 > > overloaded all overloadable operators there would be no point in > > users > > doing it. > > Agreed. But I don't have a strong opinion on whether the library should > implement everything, or just be more open to user extensions. > > > The following als looks as something I would see often in the code: > > > > assert(std::ranges::all_of(records, _1 != nullptr)); > > Definitely. That's the kind of motivating example that i think should > appear in the documentation. > > Regards, > > Julien > > > > ------------------------------ > > Message: 10 > Date: Fri, 26 Mar 2021 00:23:56 -0700 > From: Emil Dotchevski <emildotchevski(a)gmail.com> > To: Boost <boost(a)lists.boost.org> > Subject: Re: [boost] [Boost] [Describe] Summary Review Summary > Message-ID: > < > CAN5fK5H0Cr5OmaX2ryTjRcboLu8xqiv3eKuYdCaft6EZXKFh9Q(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Wed, Mar 24, 2021 at 7:35 AM Jeff Garland via Boost < > boost(a)lists.boost.org> wrote: > > > The committee seems to be concerned more with internal and external > > > politics than with serving the community. If that wasn't true there > would > > > be ZERO library additions that haven't been battle hardened by being > > > deployed and established themselves as the defacto standard already. > > > > Unlike the boost review where there's 'a decider', the committee uses > > consensus. It's a much higher bar, as frankly, it should be. > > A "much higher bar" can prevent a good library from being accepted or > prevent a bad library from being rejected. That is, consensus cuts both > ways. > > > As for battle hardened, sometimes it's not quite so simple as sometimes > > language changes are needed or vendor support is needed. Every proposal > > gets vetted for usage experience and it's clear that without experience > > it's unlikely to go forward. Is the process perfect -- no. Will it make > > everyone, even the members happy -- no. Can it be improved -- surely -- > > but like many things in life it's not as simple as we'd like. > > We can talk about the case when language changes are needed but let's focus > on libraries. > > > > The only thing they should be doing is rubber-stamping libraries that > are > > > already the standard for doing something. > > > > And if we 'just did that', things like generic programming wouldn't exist > > in c++. If the 'Roque Wave' container design was adopted in 1998 the > world > > would be very different now. > > There was no GitHub in 1998. Today it feels like some authors treat the > standard library as a vehicle for making their library available everywhere > in hopes it'll get adopted. All I'm saying is that adoption should come > before standardization. Git pull requests are better than Subversion > commits. > > > And if you want one of those 'battle hardened' libraries > > adopted, that's fine > > You see, I think it is problematic to "want" to standardize a library. IMO > the standardization process should be dull and boring, rather than driven > by exciting innovation. > > > ------------------------------ > > Message: 11 > Date: Fri, 26 Mar 2021 10:11:43 +0000 > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > To: Boost mailing list <boost(a)lists.boost.org> > Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 > Message-ID: > <CALnjya9TV+n=N-0_8zWsu_+zGTAW= > xezCsQ4C3vnBU6wZ6LkNw(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Fri, 26 Mar 2021 at 04:54, Andrzej Krzemienski via Boost > <boost(a)lists.boost.org> wrote: > > > > This is an interesting observation. In my experience, storing collections > > of ints is a rare case in production code (it is frequent in tests, > > tutorials, books, presentations), maybe this is why arithmetic operators > do > > not appear as something practical. > > They do appear frequently if you use column-oriented data structures, > which are generally better at dealing with large collections of data. > > > ------------------------------ > > Message: 12 > Date: Fri, 26 Mar 2021 10:16:17 +0000 > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > To: Boost mailing list <boost(a)lists.boost.org> > Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22, > 2021 to March 31, 2021 > Message-ID: > < > CALnjya8bbeFs1d4q2pSbr8azU3aELbXVDtyCDtj+xioUDdkaEw(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Mon, 22 Mar 2021 at 02:35, Joel de Guzman via Boost > <boost(a)lists.boost.org> wrote: > > > > The Boost formal review of the Lambda2, authored by Peter Dimov, > > starts Monday, March 22, 2021 to March 31, 2021 (inclusive). > > > > Documentation: https://pdimov.github.io/lambda2/doc/html/lambda2.html > > Source: https://github.com/pdimov/lambda2/ > > > > Lambda2 is a simple, but functional, C++14 lambda library. It takes > advantage > > of the fact that the standard <functional> header already provides > placeholders > > _1, _2, _3, and so on, for use with std::bind, and function objects such > > as std::plus, std::greater, std::logical_not, and std::bit_xor, > corresponding to > > arithmetic, relational, logical and bitwise operators. > > > > Please provide in your review information you think is valuable to > > understand your choice to ACCEPT or REJECT including Lambda2 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? > > It is not clear from the documentation what the capture behaviour of > terminals is. > I assume it's capturing rvalues by value and lvalues by reference? > > What about the expression tree itself, is it fully by value, and > therefore safely copyable? > Boost.Proto for example by default is binding everything by reference, > meaning that you couldn't even store the expression in a variable. Is > it avoiding this issue? > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > ------------------------------ > > End of Boost Digest, Vol 6566, Issue 1 > ************************************** >

1 0

[GSoC] Boost.Real: Introduction and Guidence
by Suraj Nehra 28 Mar '21

28 Mar '21

Hi, I am Suraj Nehra, a pre-final year student at the National Institute of Technology (NIT), Warangal, India. This mail is to introduce myself to the boost community. Boost.Real is not added to boost project ideas page yet but I was discussing ideas with Vikram(vikram2000b(a)gmail.com) and also made several contributions to the library. I wish to work on this library in this GSoC and will start drafting the proposal. I received the competency task from Vikram and will start working on those. I was informed of the following potential ideas by him: 1. Library comparison and benchmarking with other similar libraries. 2. DAG internal representation 3. Propose and implement optimizations for trigonometric functions. I wish to work on ideas 1 and 3. I will start making the proposal for these ideas and share the draft with you. It will be a pleasure to hear any suggestions and guidance from you. Thanks & Regards Suraj Nehra

1 0

(no subject)
by Suraj Nehra 28 Mar '21

28 Mar '21

Hi, I am Suraj Nehra, a pre-final year student at the National Institute of Technology (NIT), Warangal, India. This mail is to introduce myself to the boost community. Boost.Real is not added to boost project ideas page yet but I was discussing ideas with Vikram(vikram2000b(a)gmail.com) and also made several contributions to the library. I wish to work on this library in this GSoC and will start drafting the proposal. I received the competency task from Vikram and will start working on those. I was informed of the following potential ideas by him: 1. Library comparison and benchmarking with other similar libraries. 2. DAG internal representation 3. Propose and implement optimizations for trigonometric functions. I wish to work on ideas 1 and 3. I will start making the proposal for these ideas and share the draft with you. It will be a pleasure to hear any suggestions and guidance from you. Thanks & Regards Suraj Nehra

1 0

To contact project's mentor for GSoC21
by prince raj 26 Mar '21

26 Mar '21

Hello, My self Anish Kumar Singh and I want to participate to in boost organisation. But I have no idea how to contact mentor for project discussion and my ideas with him. So please help me contacting to mentor so that I can make my proposal good to summit. Thankyou...

3 2

[Boost] [Describe] Summary Review Summary
by Richard Hodges 26 Mar '21

26 Mar '21

Boost Describe Review Summary Boost Describe was submitted by Peter Dimov. The review period lasted from 1st March 2021 until 10th March 2021, inclusive. Overall Verdict Boost.Describe has been accepted into Boost. Detailed Results In all, 13 people submitted reviews. Of these 13, 11 reviews were an unconditional ACCEPT. The remaining two reviews were marked CONDITIONAL ACCEPT. This seems to be common practice, as committing firmly to accept or reject can seem like a bold position either way. However the Boost review process has no provision for attaching conditions to library acceptance. The verdict must be either that the library is sufficiently well written and documented, as well as providing sufficient utility, to be included in the Boost offering, or it is not. Conditional Acceptances In this review I counted the two remaining conditional acceptances as ACCEPT, and decided to pass the conditions as comments/suggestions on to the author for consideration, as well as enumerate them in this report in the hope that further study/debate is stimulated. Libraries evolve over time, and the comments will no doubt be useful to Peter when making future decisions about Boost.Describe. I will deal with the conditions mentioned by Julain Blanc first. Julian’s concerns centered around the fact that the bitfield supplied to the describe_members macro is not additive. I will quote his example here. Given the following code: struct C { int a; std::string b; double c; void f(float a, int b) { } void g() { } static void s() {} private: int p_; void h_(std::string const& s) {} BOOST_DESCRIBE_CLASS(C, (), (a, b, c, f, g, s), (), (p_, h_)) }; I would expect the following: static_assert(mp_size<describe_members<C, mod_public>>::value == 6); static_assert(mp_size<describe_members<C, mod_private>>::value == 2); That's not the case. Instead, the results are resp 3 and 1. By default, only data members are returned, not member functions. So, let's try another one. I want all my member functions: static_assert(mp_size<describe_members<C, mod_function | mod_public | mod_protected | mod_private >>::value == 4) --> fails. By default, it only returns non-static functions. So, let's try to include static function as well: static_assert(mp_size<describe_members<C, mod_static | mod_function | mod_public | mod_protected | mod_private >>::value == 4) That also fails. The result is one, now i only get the static functions. It looks that there's a mix of apples and orange in this enum. Some values acts as they will include more data in the results, some on the contrary will filter, and some will change completely the type of the members enumerated. This concern resonates with me, as I raised a similar (but less well written) query with Peter in the same area. Barrett Adair was the author of the second conditional accept. His reasoning was along the same lines as Julian’s, quoted: I don't like that I need to call describe_members multiple times to get static, non-static, data, and functions. I would appreciate the addition of mod_data and mod_nonstatic to keep the flags consistent. This is my only acceptance condition. Peter took time to respond to this concern: The reason the static/nonstatic and data/function members are returned separately is that the type of `pointer` changes. For nonstatic data, it's M T::*. For static data, it's M*. For nonstatic function, it's R (T::*)(A...). For static function, it's R (*)(A...). Since one typically does things with `pointer` in the loop over members, it's rarely the case that you want all of these at once, because the syntactic form of the code manipulating them changes. So I've found it in practice more convenient to separate them by default. It is fair to say that in less recent variants of C++, iterating over different pointer types would be problematic, although arguably less so with later variants of C++ if some accessor function template overloads or CPOs were made available in the library. The decision on whether this should be explored rests with Peter. Documentation and Examples Reviewers almost universally commented on the quality and completeness of the documentation. Particular attention was drawn to the numerous examples that clearly represent common real-world use cases. Features Requested Rainer Deyke requested the ability to annotate members with further attributes. Peter responded that he would look into whether this was possible while retaining compatibility with likely future standards adoptions of reflection, which is a design goal of the library. Maximilian Riemensberger wondered whether it would be possible to support reference members and overloaded functions. Peter’s response was that alas, no. The language itself is a limiting factor there. Maximilian also requested the ability to annotate enums with associated data. For example, representing an enum value as text when the text cannot be reasonably computed from the value’s symbolic name. Peter agreed to consider this further. Maximilian also touched on the single-pass iteration issue, which brings the number of observers who feel there is good grounds for future evolution to four. Overall Usefulness of the Library The reviewers were unanimous in calling out the need for this kind of library. From reading the reviews it is apparent that a great deal of developer effort is duplicated in writing custom reflection mechanisms. It struck me that (any kind of) language-level compile-time reflection would be welcomed with open arms by the developer community. Perhaps we can hope that the acceptance of Describe into Boost and its subsequent use can inform and encourage the C++ language group to bring something to the community sooner than later. Please join me in extending gratitude to Peter, who has taken time and painstaking effort to present us with such a useful, succinct and well documented library. Please also join me in thanking the reviewers, who can be sure that the detailed analysis included has been read and in for the most part, already elicited a response/bug-fix from Peter. Sincerely, Richard Hodges -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 mobile: +376380212

12 31

C++17 and "Alice in Wonderland"
by Edward Diener 24 Mar '21

24 Mar '21

I apologize for this non-Boost related post, but I ran into what I thought was a C++17 bug in clang ( also in vc++14.2 C++17 ), whose explanation to me of why it is not a bug really sounds like the non-logic of "Alice in Wonderland". I am not putting down the person who explains to me why it is not a bug in any way, as I know he is a C++ expert, but if this is really C++17 something must be wrong with my admittedly limited understanding of C++ and where it is going. My bug report is at https://bugs.llvm.org/show_bug.cgi?id=49684 and the explanation given there just eludes me as to what C++17 is doing, as my further comments makes apparent. Does anyone actually understand how this can possibly be ? How does C++17 apparently deduce a template argument different from what the actual type is and than declare therefore a mismatch ? This is really something from another world. My apologies for bringing this up in Boost, as it is purely a C++ issue, but my original problem comes from something I have been working on in the hopes it might eventually be a Boost library, so I decided to see if any of the expert Boost contributors might know what is going on in C++17. I realize that if everyone did as I have done here the mailing list would be a mass of irrelevant posts not Boost related.

9 11

Boost 1.76 beta - linking error when including Boost
by Luigi Ballabio 24 Mar '21

24 Mar '21

Hello, I'm afraid I don't have a minimal example yet, but I thought I'd give you a heads-up in case it rings a bell. I've been trying the Boost 1.76 beta to build a library I'm maintaining. The library builds, but when I link it to an executable I'm getting an "undefined reference to `bool boost::math::isnan<long double>(long double)". Everything works with 1.75 and earlier. My code is not using boost::math::isnan directly, so I'm guessing some other included boost component is forward-declaring it or doing something similar? The linking error disappears if I include <boost/math/special_functions/fpclassify.hpp> in a config file that is included by every file in the library. Today I'll try to pinpoint the problem by removing it there and including it before specific boost headers in the source files, but as I said, I'm posting this in case someone already has an idea about the underlying issue. Thanks, Luigi

3 4

Any Interest in a port of ZLib to C++?
by Vinnie Falco 24 Mar '21

24 Mar '21

Beast currently has its own port of ZLib to C++: <https://github.com/boostorg/beast/tree/develop/include/boost/beast/zlib> Is there any interest in having this proposed as its own separate Boost library (with a separate review, which has nothing to do with Beast)? The differences would be as follows: * Ported to use C++11 idioms * Same header-only / compiled source model as Boost.JSON * Better documentation and clear API * Improved tests Programs which use this C++ port of ZLib would get their zlib dependency from Boost instead of the official zlib distribution. And they can integrate it into their projects the same way that Boost libraries are integrated. Or they can include <boost/zlib/src.hpp> in any one translation unit (like JSON). The motivation for this is twofold: * Provide an easier way for users to access ZLib's functionality * To use this in some new libraries that I'm going to propose -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

11 14

[Boost.JSON] Security Review
by Vinnie Falco 23 Mar '21

23 Mar '21

As part of our commitment to producing the very finest C++ libraries that application developers can trust, the C++ Alliance has commissioned Bishop Fox to perform a security audit of the Boost.JSON library. The report is linked here: <https://cppalliance.org/pdf/C%20Plus%20Plus%20Alliance%20-%20Boost%20JSON%2…> This will report will be published starting in Boost 1.76.0 -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

1 0