- Boost - lists.boost.org

gsoc21: Boost.Multiprecision: New Quad-Double Backend Type: Project 1: Implement a Feasible Realization of Quad-Double
by Orlando Nkengafac 29 Mar '21

29 Mar '21

Hello, My Name is Orlando. I am a nursing student at the Faculty of Health Sciences at the University of Buea, Cameroon. However, I have had in-depth private studies in C++. What is my next step for the test and submission of a proposal, for gsoc21: “Project 1: Implement a Feasible Realization of Quad-Double”. I would like to have a mentor? Sincerely, Orlando

1 0

gsoc21: Boost.uBlas: Matrix and Tensor Computations: Project 3: Finalize Dataframe Implementation
by Fatima Zifac 29 Mar '21

29 Mar '21

Hello, My name is Fatima. I study accounting in the University of Buea, Cameroon. However, I am very good in C++. I want to do the test and submit a proposal for gsoc21: “Project 3: Finalize Dataframe Implementation”. I would like to have a mentor? Sincerely, Fatima

1 0

gsoc21: Boost.uBlas: Matrix and Tensor Computations: Project 2: Create New Matrix and Vector Types
by Forcha Pearl 29 Mar '21

29 Mar '21

Hello, My name is Pearl. I am a student at the Faculty of Engineering, in University of Buea, Cameroon. I am enrolled for a Master’s Degree in Network Engineering and Security. I would like to do gsoc21: “Project 2: Create new matrix and vector types”. I would like to have a mentor? Regards, Pearl

1 0

gsoc21: Boost.uBlas: Matrix and Tensor Computations: Project 1: Finalize and Improve the Subtensor Type
by Glen forcha 29 Mar '21

29 Mar '21

Hello, I am Glen. I am doing my Phd in Software Engineering, at the University of Buea, Cameroon. I am interested in gsoc21: “Project 1: Finalize and Improve the Subtensor Type”. I would like to have a mentor? Regards, Glen

1 0

Re: [boost] [Boost][GIL][GSOC 2021] Contribute to the library
by sayan chaudhuri 28 Mar '21

28 Mar '21

Hello Everyone, I wish to convey my thanks to Matseuz Loskot and Pranam Lashkari, maintainers of Boost GIL for taking out time to go through my mail posting and also my pull request for KMeans Clustering. I have made the changes as suggested by Pranam Lashkari by replacing the .cpp file in example folder with .hpp file in the image_processing folder. I would request to kindly have a look at the submitted changes. Here is the link for the pull request : https://github.com/boostorg/gil/pull/587.. I shall soon be posting my project proposal in the mailing list.

1 0

[Boost][GIL][GSOC 2021] Contribute to the library
by sayan chaudhuri 28 Mar '21

28 Mar '21

Hello Everyone, My name is Sayan Chaudhuri. I am a final year,undergraduate student,in the Computer Science and Engineering department of IEM,India . I am eager to participate in the GSOC 2021 and willing to contribute to the Boost GIL library. I have already gone through the wiki list of Boost GIL listing the various image processing and computer vision algorithms that have not been implemented yet. I have also gone through the Contributing documents for BOOST GIL. . While going through the Boost Mailing List Archives, I found that Igor Antropov had suggested to develop ORB descriptor during his GSOC tenure but it has not been implemented yet.. I am therefore eager to develop the ORB descriptor for Boost GIL during GSOC 2021. ORB is useful in many situations like object recognition and structure for motion and also it is suitable for real time applications unlike SIFT and SURF. I also found out that while using Boost , everytime I need to see the output , I need to save the output in order to view it,thereby unnecessarily wasting memory when I do not wish to save the output. So, the functionality of imshow() for OPENCV is missing for Boost GIL. I am also eager to work on that functionality as well during GSOC 2021. Would therefore anyone is interested in mentoring me? As my programming competency test for Boost GIL, I have implemented the KMeans algorithm from scratch using Boost GIL and I have raised a pull request- https://github.com/boostorg/gil/pull/587. I would kindly request if someone can kindly review it. Also, I would like to know whether there are any similar issues that I can work on currently.

2 1

Re: [boost] 14 to contact for introduction and guidance with gsoc mentor.
by Chandana Gubba 28 Mar '21

28 Mar '21

Sir/madam I does not have that great idea regarding Gsoc ,so firstly I want to know what about it exactly and how to apply and do project,and even about the eligibility ,I am ok with c++ programming. Is it enough ,these are my queries regarding gsoc. On Sun, 28 Mar, 2021, 7:20 pm , <boost-request(a)lists.boost.org> wrote: > 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 (Peter Dimov) > 2. Re: [Lambda2] Review starts Monday March 22, 2021 to March > 31, 2021 (Peter Dimov) > 3. To contact project's mentor for GSoC21 (prince raj) > 4. Re: To contact project's mentor for GSoC21 > (Vin?cius dos Santos Oliveira) > 5. Re: To contact project's mentor for GSoC21 (Mateusz Loskot) > 6. Re: [Lambda2] Review starts Monday March 22, 2021 to March > 31, 2021 (Christian Mazakas) > 7. Re: [Boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 (Emil Dotchevski) > 8. Re: [Lambda2] Review starts Monday March 22, 2021 to March > 31, 2021 (Phil Endecott) > 9. Re: [Lambda2] Review starts Monday March 22, 2021 to March > 31, 2021 (Peter Dimov) > 10. [Boost][GIL][GSOC 2021] Contribute to the library > (sayan chaudhuri) > 11. (no subject) (Suraj Nehra) > 12. [GSoC] Boost.Real: Introduction and Guidence (Suraj Nehra) > 13. Changelog for 1.76 is outdated (Antony Polukhin) > 14. Re: Changelog for 1.76 is outdated (Antony Polukhin) > 15. Re: Boost Digest, Vol 6566, Issue 1 (shady mohamed) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 26 Mar 2021 14:10:43 +0200 > From: "Peter Dimov" <pdimov(a)gmail.com> > To: <boost(a)lists.boost.org> > Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22, > 2021 to March 31, 2021 > Message-ID: <144201d72239$0c182c30$24488490$(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > Mathias Gaunard wrote: > > 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? > > The capture behavior is inherited from std::bind, which captures > everything by value by default unless overridden with std::ref. > > > > ------------------------------ > > Message: 2 > Date: Fri, 26 Mar 2021 14:19:24 +0200 > From: "Peter Dimov" <pdimov(a)gmail.com> > To: <boost(a)lists.boost.org> > Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 > Message-ID: <144401d7223a$42e76ef0$c8b64cd0$(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > Andrzej Krzemienski wrote: > > 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. > > I'll add the shift operators and the unary * at minimum, will see about any > others. The current set is determined by the function objects in > <functional>. > > > > ------------------------------ > > Message: 3 > Date: Fri, 26 Mar 2021 20:50:52 +0530 > From: prince raj <sdavil318(a)gmail.com> > To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> > Subject: [boost] To contact project's mentor for GSoC21 > Message-ID: <B9EC3FCE-61E8-47E7-8665-FFFE6088824F(a)hxcore.ol> > Content-Type: text/plain; charset="utf-8" > > > > 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... > > > ------------------------------ > > Message: 4 > Date: Fri, 26 Mar 2021 12:46:26 -0300 > From: Vin?cius dos Santos Oliveira <vini.ipsmaker(a)gmail.com> > To: Boost <boost(a)lists.boost.org> > Cc: prince raj <sdavil318(a)gmail.com> > Subject: Re: [boost] To contact project's mentor for GSoC21 > Message-ID: > < > CAK9RveLeh66nHX-ZBRpPs4mP+fDZ5JjwN3beVVRd8X0dnHCvRA(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Em sex., 26 de mar. de 2021 ?s 12:22, prince raj via Boost < > boost(a)lists.boost.org> escreveu: > > > But I have no idea how to contact mentor for project discussion and my > > ideas with him. > > > > What's the project you're interested in? > > > -- > Vin?cius dos Santos Oliveira > https://vinipsmaker.github.io/ > > > ------------------------------ > > Message: 5 > Date: Fri, 26 Mar 2021 17:32:14 +0100 > From: Mateusz Loskot <mateusz(a)loskot.net> > To: boost(a)lists.boost.org > Subject: Re: [boost] To contact project's mentor for GSoC21 > Message-ID: > < > CABUeae8fsFiX6CS6_HXH-u59_GQJscbEdEJEZ-W0naq_WJRHiA(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Fri, 26 Mar 2021 at 16:22, prince raj via Boost > <boost(a)lists.boost.org> wrote: > > > > 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. > > First, read this and the materials linked there > https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code%3A-Overview > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > > > ------------------------------ > > Message: 6 > Date: Fri, 26 Mar 2021 19:45:39 -0700 > From: Christian Mazakas <christian.mazakas(a)gmail.com> > To: "boost(a)lists.boost.org List" <boost(a)lists.boost.org> > Cc: Peter Dimov <pdimov(a)gmail.com> > Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 > Message-ID: > < > CAHf7xWsqNHEt8-nxBRFz1+BjNMiwXasoYsFOuFR+tpd2EWZkog(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hey everyone, > > I vote to *ACCEPT *Lambda2. > > I first heard of Lambda2 when Peter asked me how many lines I thought > it would take to recreate Boost.Lambda. > > Naturally, I should've seen this as a loaded question but I guessed a few > hundred. Maybe something just below a couple thousand by the time all > the dust settles. > > Peter told me it could be done in ~50 lines. Now I was intrigued. The > source code of > Lambda2 is wonderfully clever and short. Moreso, sufficiently clever that > it's worth > not repeating every time we want to use it. > > Higher-order functions are all the rage in C++ and writing lambdas is > cumbersome > and annoying. Lambda2 gives us a C++14 solution that relies on nothing else > but > simple language features and stdlib headers making it faster to compile > than older > solutions such as Phoenix or the original Lambda. > > Lambda2 also has the fortune of interop'ing greatly with existing > constructs like > Boost.HOF and the new `<ranges>` STL header. See: > https://godbolt.org/z/hfxfhfEqv > > Keeping this short, Lambda2 gives us fresh paint over an old technology > that we know > works and one that (while polarizing in its style) does its job well. I > think it ultimately > serves Boost and the larger C++ community to keep this Lambda-style of > coding alive > and well-maintained as C++ evolves. > > - Christian > > > ------------------------------ > > Message: 7 > Date: Fri, 26 Mar 2021 23:18:47 -0700 > From: Emil Dotchevski <emildotchevski(a)gmail.com> > To: Boost <boost(a)lists.boost.org> > Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22, > 2021 to March 31, 2021 > Message-ID: > <CAN5fK5HJmHeZOoQ-nYwrHxKnQMjcAX8bLR4KMKz3= > QsXwrM-Pw(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Here is my review of lambda2: > > I remember when I first learned boost::bind, and realized how much more > useful STL is because of it. Even after C++11 I still find myself using > bind, it sometimes looks more readable to my eyes than a lambda. > > The lambda2 library is one more proof for the solid design behind > std::bind. That, or std::bind was designed with things like lambda2 in > mind. Either way, lambda2 is an elegant utility for writing elegant C++, > albeit only in the (rare?) cases when it is a perfect fit. Given this, and > the miniature size of the library, my vote is to ACCEPT. > > > ------------------------------ > > Message: 8 > Date: Sat, 27 Mar 2021 17:42:36 +0000 > From: "Phil Endecott" <spam_from_boost_dev(a)chezphil.org> > To: <boost(a)lists.boost.org> > Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 > Message-ID: <1616866956454(a)dmwebmail.dmwebmail.chezphil.org> > Content-Type: text/plain; format="flowed"; charset="UTF-8" > > Peter Dimov wrote: > > The goals of the library are > > [...] > > - Prepare a proposal to extend the standard with these same additions by > > gathering experience in Boost first. > > Am I correct in thinking that this functionality could have been > added to the standard library when std::bind was added in C++11, > except that it requires something in the core language that was not > added until C++14 ? > > If not, what is the reason why this was not added when std::bind > was added? (I've failed to locate any pre-C++11 WG21 papers about > std::bind.) > > > Regards, Phil. > > > > > > > ------------------------------ > > Message: 9 > Date: Sat, 27 Mar 2021 19:58:03 +0200 > From: "Peter Dimov" <pdimov(a)gmail.com> > To: <boost(a)lists.boost.org> > Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 > Message-ID: <14fe01d72332$bc76fad0$3564f070$(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > Phil Endecott wrote: > > Peter Dimov wrote: > > > The goals of the library are > > > [...] > > > - Prepare a proposal to extend the standard with these same additions > by > > > gathering experience in Boost first. > > > > Am I correct in thinking that this functionality could have been added > to the > > standard library when std::bind was added in C++11, except that it > requires > > something in the core language that was not added until C++14 ? > > Return type deduction makes it easier to write, and the function objects in > <functional> acquired their <void> forms in C++14, but it's possible to > make > this work in C++11 as well. > > > If not, what is the reason why this was not added when std::bind was > added? > > (I've failed to locate any pre-C++11 WG21 papers about std::bind.) > > I didn't propose it. :-) > > > > ------------------------------ > > Message: 10 > Date: Sat, 27 Mar 2021 22:38:36 +0530 > From: sayan chaudhuri <sayanchaudhuri758(a)gmail.com> > To: boost(a)lists.boost.org > Subject: [boost] [Boost][GIL][GSOC 2021] Contribute to the library > Message-ID: > <CAJH= > o2N_rOMqaPg+jt823+Nj9Z+fD+w-4LqQw8ZOOBkEUMAUzw(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hello Everyone, > My name is Sayan Chaudhuri. I am a final > year,undergraduate student,in the Computer Science and Engineering > department of IEM,India . I am eager to participate in the GSOC 2021 and > willing to contribute to the Boost GIL library. > I have already gone through the wiki list of Boost > GIL listing the various image processing and computer vision algorithms > that have not been implemented yet. I have also gone through the > Contributing documents for BOOST GIL. . While going through the Boost > Mailing List Archives, I found that Igor Antropov had suggested to develop > ORB descriptor during his GSOC tenure but it has not been implemented yet.. > I am therefore eager to develop the ORB descriptor for Boost GIL during > GSOC 2021. ORB is useful in many situations like object recognition and > structure for motion and also it is suitable for real time applications > unlike SIFT and SURF. I also found out that while using Boost , everytime I > need to see the output , I need to save the output in order to view > it,thereby unnecessarily wasting memory when I do not wish to save the > output. So, the functionality of imshow() for OPENCV is missing for Boost > GIL. I am also eager to work on that functionality as well during GSOC > 2021. Would therefore anyone is interested in mentoring me? > As my programming competency test for Boost GIL, I > have implemented the KMeans algorithm from scratch using Boost GIL and I > have raised a pull request- https://github.com/boostorg/gil/pull/587. I > would kindly request if someone can kindly review it. Also, I would like to > know whether there are any similar issues that I can work on currently. > > > ------------------------------ > > Message: 11 > Date: Sun, 28 Mar 2021 03:22:35 +0000 > From: Suraj Nehra <surajnehra112(a)gmail.com> > To: boost(a)lists.boost.org > Subject: [boost] (no subject) > Message-ID: > <CAJR02FfuUhWpDYveadts9Xd5QD5_tzV5z= > hgMmar1greSBmzSw(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > 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 > > > ------------------------------ > > Message: 12 > Date: Sun, 28 Mar 2021 03:30:54 +0000 > From: Suraj Nehra <surajnehra112(a)gmail.com> > To: boost(a)lists.boost.org > Subject: [boost] [GSoC] Boost.Real: Introduction and Guidence > Message-ID: > < > CAJR02Fe4w-FfDcjDK4NfLs1LNqBwThi5uxF-nhefMo6NhrSSkw(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > 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 > > > ------------------------------ > > Message: 13 > Date: Sun, 28 Mar 2021 09:54:11 +0300 > From: Antony Polukhin <antoshkka(a)gmail.com> > To: "boost(a)lists.boost.org List" <boost(a)lists.boost.org> > Subject: [boost] Changelog for 1.76 is outdated > Message-ID: > < > CAKqmYPazb_JKWwwy-DZGdpfseJ4wB0KXR3FsK22o-nZ0w6G+0Q(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi, > > The https://www.boost.org/users/history/version_1_76_0.html seems quite > outdated. Please update > > Thanks in advance! > > > ------------------------------ > > Message: 14 > Date: Sun, 28 Mar 2021 09:56:43 +0300 > From: Antony Polukhin <antoshkka(a)gmail.com> > To: "boost(a)lists.boost.org List" <boost(a)lists.boost.org> > Subject: Re: [boost] Changelog for 1.76 is outdated > Message-ID: > <CAKqmYPaXN-c= > k45pCMWVDYAdHX+p916H2fjkfHXZ4pvVchRV6A(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > By "outdated" I mean that > > https://github.com/boostorg/website/blob/master/feed/history/boost_1_76_0.q… > has more info > > > ------------------------------ > > Message: 15 > Date: Sun, 28 Mar 2021 15:05:07 +0200 > From: shady mohamed <shadimabdrawy1999(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] Boost Digest, Vol 6566, Issue 1 > Message-ID: > < > CAPwR5ipUjbt4R5E_W4qO3wvfkm7NfmiT1Q99AhMwWvGxTUyk2A(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > 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 > > ************************************** > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > ------------------------------ > > End of Boost Digest, Vol 6567, Issue 1 > ************************************** >

2 1

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