March 2021 - Boost - lists.boost.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 200

Boost.Text is looking for a (mini-)review manager
by Zach Laine 07 Dec '22

07 Dec '22

I've made all the recommended changes to Boost.Text that came up in the review. Glen, the previous review manager, recommended a mini review of Boost.Text once I'd made those changes. If you'd like to manage the mini-review, please let me know. For everyone, including potential reviewers and review managers, here are the major changes: * All the specific review feedback issues have been addressed. * The string layer is now gone. * The text layer got a major re-work. It is now a set of template-based adaptors (basic_text<>, vs. a text typedef. etc.), which lets everyone get what they want. You can change the underlying storage type (including whatever allocator you prefer), select UTF-8 or UTF-16, and change the normalization form. Glen recommended I drop this layer, but the library is way less useful without this stuff, and these changes address all the concerns raised about the text layer in the review. The updated docs can be found here: https://tzlaine.github.io/text/doc/html/index.html Oh yeah, and I added concept constraints to the whole library when you build in C++20 mode. Zach

17 46

[review][JSON] Review of JSON starts today: Sept 14 - Sept 23
by Pranam Lashkari 09 Aug '22

09 Aug '22

Boost formal review of Vinnie Falco and Krystian Stasiowski's library JSON starts today and will run for 10 days ending on 23 Sept 2020. Both of these authors have already developed a couple of libraries which are accepted in Boost(boost beast and Static String) This library focuses on a common and popular use-case for JSON. It provides a container to hold parsed and serialised JSON types. It provides more flexibility and better benchmark performance than its competitors. JSON highlights the following features in the documentation: - Fast compilation - Require only C++11 - Fast streaming parser and serializer - Easy and safe API with allocator support - Constant-time key lookup for objects - Options to allow non-standard JSON - Compile without Boost, define BOOST_JSON_STANDALONE - Optional header-only, without linking to a library (a point I would like to add in highlight: it has cool Jason logo 😝) To quickly understand and get the flavour of the library take a look at "Quick Look" <http://master.json.cpp.al/json/usage/quick_look.html> You can find the source code to be reviewed here: <https://github.com/CPPAlliance/json/tree/master> You can find the latest documentation here: <http://master.json.cpp.al/> Benchmarks are also given in the document which can be found here: <http://master.json.cpp.al/json/benchmarks.html> Some people have also given the early reviews, the thread can be found here: <https://lists.boost.org/Archives/boost/2020/09/249745.php> Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including JSON 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? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: <http://www.boost.org/community/reviews.html> Thank you for your effort in the Boost community. -- Thank you, Pranam Lashkari, https://lpranam.github.io/

21 73

[container] Contributing 'stationary_vector' to Boost
by Mehrdad Niknami 13 Jun '22

13 Jun '22

Hi all, Happy new year! New mailing list member here. I've developed an STL-style stationary_vector class that retains elements in-place when growing. Very briefly, it is effectively a piecewise-contiguous vector, with the following advantages over vector: - Appending has O(1) overhead in the *worst* case (e.g., push_back() does not move elements) - Insertion and random-access can be done in parallel, as prior iterators & references remain valid This has a variety of benefits, including better UX (no "hiccups" due to reallocations), and the ability to simplify parallel processing of streaming data. It occurred to me the larger C++ community might find this useful. I was wondering if there would be interest in incorporating it into Boost.Container, and if so, what steps I could take to make that happen? I'm of course happy to discuss the design etc. with anyone who might be interested. Summary: https://github.com/mehrdadn/libvital/blob/master/doc/vital/container/statio… Implementation: https://github.com/mehrdadn/libvital/blob/master/include/vital/container/st… Thank you, Mehrdad

7 19

Adding my sorting algorithm, ska_sort, to boost, attempt 2
by Malte Skarupke 24 Nov '21

24 Nov '21

Hi everyone, I started a discussion about this in October, but at the time the maintainer of the sort library was busy, then I was busy, so now it's January... I wrote a generalized version of radix sort a couple years ago and gave a talk about it here: https://www.youtube.com/watch?v=zqs87a_7zxw I would like to get a new version of that sorting algorithm into boost. It's faster than what I showed several years ago. It's also even more general and has a new interface that should be easier to extend. I uploaded the code here: https://github.com/skarupke/sort/tree/master The documentation is also already updated with new benchmark results. Let me know what's required to get this into boost. Would you like this in the form of a pull request? One of the big things that probably needs review is the interface, since radix sorting works differently than comparison based sorting. For most normal uses you just need to provide a sort key, but more complicated cases can get more complicated. I tried very hard to make everything easy, but I'd also be curious if others can come up with better ways of doing the interface. Thanks, Malte -- Malte Skarupke malteskarupke(a)fastmail.fm

8 10

wrong result in complex pow
by Gero Peterhoff 03 May '21

03 May '21

Hello, the pow-function pow(scalar, complex) in boost/math/cstdfloat/cstdfloat_complex_std.hpp get wrong result. Current implementation: inline complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE> pow(const BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE& x, const complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE>& a) { return std::exp(a * std::log(x)); } I think that's correct: inline complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE> pow(const BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE& x, const complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE>& a) { return std::exp(a * std::log(complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE>(x))); } regards Gero

6 25

The descriptor does not fit into the select call's fd_set
by George Nistor 10 Apr '21

10 Apr '21

Hi all, I am having a problem with the following error message '' The descriptor does not fit into the select call's fd_set" The setup I have is QNX , VSomeIP lib (socket abstractisation lib) , lib Boost 1.61 (a very old version) I get the error in this lib VSomeIp from the bellow boost call. The call to boost::asio::async_write(3 params) gives the above error message. I have tried to see also on QNX with > pidin -p vsomeip fds How many open file descriptor do I have and I got value 123. As far as I know there is a limitation 1024 of open file descriptors. Could you provide some help? Does the latest boost lib solve this particular case? I appreciate any suggestion, Also please say if any info is missing Thanks George Nistor

2 1

[Boost] [Lambda2] Review starts Monday March 22, 2021 to March 31, 2021
by Joel de Guzman 08 Apr '21

08 Apr '21

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? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found at: http://www.boost.org/community/reviews.html The review is open to anyone who is prepared to put in the work of evaluating and reviewing the library. Prior experience in contributing to Boost reviews is not a requirement. Thank you for your efforts in the Boost community. They are very much appreciated. Peter is often available in the CppLang Slack #boost channel should you require any clarification not covered by the documentation. I am not frequently available in the Slack channel, but I'll certainly pay attention to the discussions. Please don't hesitate to ping me if needed. Cheers, --Joel de Guzman

17 34

FFT proposal for gsoc 2021
by Eduardo Quintana 08 Apr '21

08 Apr '21

Hi Boost community, I've been working on a C++ templated library for Fast Fourier Transforms, https://github.com/Lagrang3/fftx. Templated because some FFT algorithms are algebraic-field independent, eg. you could FFT an array of N matrices provided a Nth matrix-root-of-unity is given. As a result you could have a single algorithm for a variety of underlying, eg. `std::complex<float>`, `std::complex<double>`, `std::complex<long double>`, `boost::math::quaternion`, finite field types (this would yield the "Number theoretic transform" https://cp-algorithms.com/algebra/fft.html#toc-tgt-6) I would like to improve this library during the GSOC 2021, as a proposal for inclusion inside Boost.Math or Boost.Algorithms. Is there anyone interested in supervising this project? Any opinions? Best regards, Eduardo Quintana

6 29

[release] 1.76.0 post-beta merges
by Marshall Clow 07 Apr '21

07 Apr '21

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> Reminder: The master branch closes for the release on Wednesday, Apr 7. Full calendar here: https://www.boost.org/development/ <https://www.boost.org/development/> — Marshall P.S Doc changes and test changes do NOT require release manager approval to be merged.

12 34

[gsoc21] Feedback and advice on proposal
by Haoran Xu 04 Apr '21

04 Apr '21

Hi, I'm really interested in applying for GSoC 2021 and implementing the Boost.XML library. I have completed the competency test and have drafted by proposal. https://docs.google.com/document/d/1KP-g1zMXQdqUzSFMtsURcSpZisjjspvX8lRkdRj… Please tell me what you think this proposal is missing and what I should add on. It's my first time applying for GSoC so I'm not very familiar with the process. Thank you!

2 4

[lambda2] Andrzej's review
by Andrzej Krzemienski 02 Apr '21

02 Apr '21

Hi Everyone, I recommend to REJECT Boost.Lambda2 library in its current form. My opinion is not very strong, and it is based on the perceived trade-off between usefulness and technical problems. I acknowledge that there are practical use cases that the library can address, that are not provided in documentation. (I recommend that examples with pointers, and maybe a complex one with column-oriented design be added). I consider the ADL issue that Barry pointed out a serious one. This will be an additional place where users would suddenly be caught by a magical problem that they will spend hours understanding. I think that the main problem here is that Boost.Lambda2 defines the operators that should belong to namespace std::placeholders. I also note that if this was added to the Standard Library, the problem would be nonexistent, because they would reside in namespace std. Could I propose an alternative design. Add placeholders _1, _2, ... into namespace `boost::lambda2::placeholders` specialize std::is_placeholder` for them, so that `std::bind` can recognize them. Add operators in the same namespace. Then, recommend the following usage of the library: ``` using namespace boost::lambda2::placeholders; void fun() { auto pred = std::bind(_1, &Employee::name) == std::bind(_2, &Employee::name); } ``` This single using directive would make both `std::bind` and Boost.Lambda2 operators work. I would find such a library acceptable. And in fact I could make it a condition for a conditional acceptance. Now, the standard questions: > - What is your evaluation of the design? > I object to the choice to add operators for placeholders from one namespace (std::placeholders) into another namespace (boost::lambda2). Save for that, I find anything else good. - What is your evaluation of the implementation? > Very sweet and clean. I only expect other operators to also work. But Peter already explained that this is his plan. - What is your evaluation of the documentation? > This library doesn't require much documentation of the interface. But I fill it is missing the Motivation section. I would expect to see practical examples: not long ones, but ones that I will find in real programs, like dealing with pointers. - What is your evaluation of the potential usefulness of the library? > Others have convinced me that it will find sufficient application in real programs. - Did you try to use the library? With which compiler(s)? Did you > have any problems? > I tried to reimplement it, and played with some toy examples in Wandbox. (newest GCC). It worked fine. - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > I was able to reimplement it, read the entire implementation (which was not difficult: it is like seventy lines). I spent like three hours in total studying it. - Are you knowledgeable about the problem domain? > I used Boost.Lambda and Boost.Bind in the past. Finally, I would like to thank Peter for writing and sharing this library. Regards, &rzej;

3 9

Idea Suggestion for GsOC'21
by Sanyam Bhaskar 01 Apr '21

01 Apr '21

Hey! This is Sanyam Bhaskar. I read over the default Ideas provided to us and XML Parser really caught my eye. I would like to contribute to the same but don’t know where to start. Also, as per my understanding, XML is relatively outdated , when compared to data languages like JSON. So in addition to this being an XML Parser, I think adding a JSON parser alongside it would boost the library’s utility in the modern day industry. I Would appreciate it if someone could tell me how to get started and some feedback on the suggestion. Looking forward to contributing to the project. Yours, Sanyam Bhaskar

4 7

[range] the strange behavior of adjacent_filter
by Andrzej Krzemienski 01 Apr '21

01 Apr '21

Hi everyone, Boost.Range has two GitHub issues on the strange behavior of adjacent_find that have been sitting there for more than two years: https://github.com/boostorg/range/issues/80 https://github.com/boostorg/range/issues/81 The behavior of the algorithm is not well described, but the intuitive expectation would be that it returns for every pair of adjacent elements that match the predicate the second of the pair. However, the unexpected behavior of the algorithm is that for a non-empty range it literally always returns the first element. I do not think that this is by accident, because Ranges V3 also expose the same behavior: https://godbolt.org/z/P33j1qvT6 Does anyone happen to know the reasoning or motivation behind this behavior? Regards, &rzej;

1 0

Interested in creating new matrix and vector types
by Gagandeep Bhatia 31 Mar '21

31 Mar '21

Hey, I'm Gagandeep Bhatia, currently pursuing the 2nd year in Christ University, Bangalore, India. You can reach me at gagandeepbhatia2303(a)gmail.com or +919466935025. I went through your upcoming projects on Google Summer of Code, your idea on creating new matrix and vector types is really impressive. The best part about your project is It supports all matrix sizes, from small fixed-size matrices to arbitrarily large dense matrices, and even sparse matrices. It supports all standard numeric types, including std::complex, integers, and is easily extensible to custom numeric types. It supports various matrix decompositions and geometry features I truly want to become part of this project for a better mutual achievement, in the past I have done a few projects, which will help me to contribute my best in this project. It will be really kind if you can share some more details about your project, so I learn more about your project. with regards.

2 2

Boost.Lambda2 usage
by Barry Revzin 31 Mar '21

31 Mar '21

Hey all, I spent this morning implementing views::zip using Boost.Lambda2 (because views::zip requires writing lots of single-operator lambdas, so it fits the problem quite well). You can see the implementation here: https://godbolt.org/z/jcjdd3xeo I ran into a few issues I wanted to point out. First, several operators are missing. This is the standard library's fault (it's weird that not even dereference is there). But if the standard library isn't going to provide them, I figure Boost.Lambda2 should, since these are probably going to come up so may as well just add a few more lines of code and call it a day. I needed to define five: * (unary), ++ and -- (prefix), +=, and -=. Second, this library has name lookup issues. Here's a reduced example ( https://godbolt.org/z/z8oEqnTnG) #include < https://raw.githubusercontent.com/pdimov/lambda2/develop/include/boost/lamb… > namespace N { struct Irrelevant { }; void operator+(Irrelevant, Irrelevant); int plus_one(int i) { using namespace boost::lambda2; return (_1 + 1)(i); } } This doesn't compile. _1 + 1 finds the appropriately-named irrelevant operator+ and stops there, and we never get to the operator+ in namespace boost::lambda2. Either the operators need to be put in namespace std::placeholders for ADL (which seems naughty, but also seems like something the standard library could potentially do?) or the library should provide its own placeholders. That would lose the nice _1 name, but gain the ability to provide both [] and (). Thanks for the library, Barry

3 3

Re: [boost] [Boost][GIL][GSOC21]Wish to know about code review process
by sayan chaudhuri 30 Mar '21

30 Mar '21

Hello Everyone, I am a bit new to the world of open source and so I would like to know how the code review of pull requests is actually done. I have come to know that when I add a new feature to the library, I have to submit a test file along with my pull request. After that,what happens is unknown to me.Understanding this would help me to realize the entire process from pull requests to merging and therefore increase the quality of my contribution. I shall be highly thankful to anyone who may take time out of his/her busy schedule to explain this a bit to me. Thank you all.

2 1

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