Re: Boost Digest, Vol 6566, Issue 1
Locked
Re: Boost Digest, Vol 6566, Issue 1
 
|
I want to talk with engineer david bellot and engineer cem bassoy
Thanks في الجمعة، ٢٦ مارس، ٢٠٢١ ١٢:٢٣ م <[hidden email]> كتب: > Send Boost mailing list submissions to > [hidden email] > > 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 > [hidden email] > > You can reach the person managing the list at > [hidden email] > > 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 <[hidden email]> > To: Boost mailing list <[hidden email]> > Cc: Peter Dimov <[hidden email]> > Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22, > 2021 to March 31, 2021 > Message-ID: > <CAOenAXhsJ1yCRRBYgJuPh8xws5MMVCks7p6GvfmBG+= > [hidden email]> > Content-Type: text/plain; charset="UTF-8" > > pon., 22 mar 2021 o 16:44 Peter Dimov via Boost <[hidden email]> > 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 <[hidden email]> > To: [hidden email] > Subject: Re: [boost] [release] 1.76.0 post-beta merges > Message-ID: <[hidden email]> > 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#L35 > please. > > Niall > > > ------------------------------ > > Message: 3 > Date: Thu, 25 Mar 2021 17:24:15 +0200 > From: "Peter Dimov" <[hidden email]> > To: "'Andrzej Krzemienski'" <[hidden email]>, "'Boost mailing > list'" <[hidden email]> > Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22, > 2021 to March 31, 2021 > Message-ID: <131601d7218a$eb1033b0$c1309b10$@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 <[hidden email]> > To: Boost Developers List <[hidden email]> > Subject: Re: [boost] [release] 1.76.0 post-beta merges > Message-ID: <[hidden email]> > Content-Type: text/plain; charset=utf-8 > > On Mar 25, 2021, at 8:06 AM, Niall Douglas via Boost < > [hidden email]> 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#L35 > > please. > > Do you have a commit that fixes this? > > ? Marshall > > > > > ------------------------------ > > Message: 5 > Date: Thu, 25 Mar 2021 16:04:17 +0000 > From: Niall Douglas <[hidden email]> > To: Boost Developers List <[hidden email]> > Subject: Re: [boost] [release] 1.76.0 post-beta merges > Message-ID: <[hidden email]> > 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 < > [hidden email]> 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#L35 > >> 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 <[hidden email]> > To: [hidden email] > Subject: Re: [boost] [release] 1.76.0 post-beta merges > Message-ID: > <CAHVPgznFdSVYJ9gR8LzP7qQV7w5+fcjBvKq95ReUKkFR-ct= > [hidden email]> > Content-Type: text/plain; charset="UTF-8" > > On Thu, Mar 25, 2021 at 12:04 PM Niall Douglas via Boost > <[hidden email]> wrote: > > > > On 25/03/2021 15:45, Marshall Clow wrote: > > > On Mar 25, 2021, at 8:06 AM, Niall Douglas via Boost < > [hidden email]> 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#L35 > > >> 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 <[hidden email]> > To: [hidden email] > Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 > Message-ID: <[hidden email]> > 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 <[hidden email]> > To: Boost mailing list <[hidden email]> > Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 > Message-ID: > <CAOenAXgEDx= > [hidden email]> > Content-Type: text/plain; charset="UTF-8" > > czw., 25 mar 2021 o 19:11 Julien Blanc via Boost <[hidden email]> > 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 <[hidden email]> > To: [hidden email] > Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 > Message-ID: <[hidden email]> > 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 <[hidden email]> > To: Boost <[hidden email]> > Subject: Re: [boost] [Boost] [Describe] Summary Review Summary > Message-ID: > < > [hidden email]> > Content-Type: text/plain; charset="UTF-8" > > On Wed, Mar 24, 2021 at 7:35 AM Jeff Garland via Boost < > [hidden email]> 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 <[hidden email]> > To: Boost mailing list <[hidden email]> > Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 > Message-ID: > <CALnjya9TV+n=N-0_8zWsu_+zGTAW= > [hidden email]> > Content-Type: text/plain; charset="UTF-8" > > On Fri, 26 Mar 2021 at 04:54, Andrzej Krzemienski via Boost > <[hidden email]> 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 <[hidden email]> > To: Boost mailing list <[hidden email]> > Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22, > 2021 to March 31, 2021 > Message-ID: > < > [hidden email]> > Content-Type: text/plain; charset="UTF-8" > > On Mon, 22 Mar 2021 at 02:35, Joel de Guzman via Boost > <[hidden email]> 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 > ************************************** > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost |
«
Return to Boost - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |