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 06 Apr '21

06 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 31 Mar '21

31 Mar '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

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

28 Mar '21

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

1 0

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

28 Mar '21

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

1 0

(no subject)
by Suraj Nehra 28 Mar '21

28 Mar '21

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

1 0

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

26 Mar '21

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

3 2

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

26 Mar '21

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

12 31

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

24 Mar '21

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

9 11

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

24 Mar '21

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

3 4

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

24 Mar '21

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

11 14

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

23 Mar '21

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

1 0

boost library incubator planning shutdown
by Robert Ramey 22 Mar '21

22 Mar '21

I had high hopes for the boost library incubator when I made it. But I think it's pretty clear that those hopes haven't been realized. Maintaining and Enhancing this website required more effort than I had anticipated so it hasn't evolved. I do notice that people do use it from time to time (a couple hundred page hits/day), so it's not totally dead. But it would either have to go forward or be shut down. If someone wanted to take it over that would be fine. But I don't expect anyone to come forward so I'll be shutting it down probably in the next 30 days or so. Robert Ramey

1 0

Mentor application for Boost.Real
by Vikram Chundawat 21 Mar '21

21 Mar '21

Hello everyone, I am Vikram Singh Chundawat, I worked on Boost.Real previous GSoC and I am actively working on the library since. Now, one of the potential mentors Damian Vicino is not mentoring this year, I wish to mentor this project in GSoC 2021 with Laouen Belloli. We have some potential candidates who are working on the library and also some good ideas for the library. The aim last year was to bring Boost.Real to review ready state and some work is still remaining to make it review ready, we found some bugs in the review. Now, we are working on optimizations, bug fixes, and benchmarking. I went through the guidelines of Google and wish to know the procedure for mentor application. Thank You Regards Vikram Singh Chundawat

2 1

Proposing a library to include in Boost
by Mohit Saini 20 Mar '21

20 Mar '21

Hi, This is Mohit Saini. I developed a lazy_map library, whose interface is similar to std::unordered_map but lazy_map is O(1) copiable. Other operations like Deletion, Lookup, Insertion etc. continue to cost O(1).. which also implies that lazy_map is not a simple cow_wrapper<std::unordered_map> .. lazy_map is way more clever than that. Learn more at : https://github.com/tinytrashbin/lazy_map Specially, checkout the section which explains the "Fragment" tree. Lazy_map is heavily used in our codebase for taking snapshot of a very large state ( of size ~ 5 GBs), enabling "fork" of a snapshot in O(1) time for further modification in the forked snapshot, allowing a large number of threads to operate on different snapshots of very large size, concurrently without interfering with each other where each of the thread is even "writing" to their snapshot. I believe such a utility will be very helpful for others too. I'm looking for boost-maintainers who can review and suggest what all I need to do so that lazy_map can be accepted in Boost. Thanks -- Mohit Saini

1 0

Re: [boost] Feedback on GSoC'21 project proposal
by krushnalpatel11＠gmail.com 20 Mar '21

20 Mar '21

I have updated the proposal with the changes you proposed. Please check if all things are updated as per your feedback. https://docs.google.com/document/d/1Bvno6ifHjo8EdMRuzFqCk9AEB5IgAxf2ag4xdc4… Krushnal http://krushnal.me/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost </quote> Quoted from: http://boost.2283326.n4.nabble.com/Feedback-on-GSoC-21-project-proposal-tp4… _____________________________________ Sent from http://boost.2283326.n4.nabble.com

1 0

Re: [boost] Boost website changes and .'cxxstd'
by Donovan Dikaio 20 Mar '21

20 Mar '21

I can look into it. But needs to make the requirements clear. So, the task is to show *C++ standard minimum level: C++nn* for Standard attribute for each lib in this page: C++ standard minimum level: C++nn ? And we could replace nn with the actual number by checking the *cxxstd* key in a library's meta info json file. Please let me know if I got it right. On Fri, Dec 25, 2020 at 10:00 AM Louis Tatta <louis(a)cppalliance.org> wrote: > > > ---------- Forwarded message --------- > From: Edward Diener via Boost <boost(a)lists.boost.org> > Date: Wed, Dec 23, 2020 at 7:39 PM > Subject: [boost] Boost website changes and .'cxxstd' > To: <boost(a)lists.boost.org> > CC: Edward Diener <eldiener(a)tropicsoft.com> > > > Even though I have worked a little with PHP in the past I do not have > the talent to make the change to the website which would incorporate the > addition of the meta information json field 'cxxstd' to the Boost > documentation web page for each library. The idea is that if 'cxxstd' is > set to a value the documentation for that library would also show: > > C++ standard minimum level: C++nn > > where nn would be 11, 14, 17, or 20 depending on the value of 'cxxstd'. > Alternatively if there is no 'cxxstd' entry for a library or if the > value of 'cxxstd' is '03', we could either specify 'nn' as '03' or leave > off the line stating the 'C++ standard minimum level completely. > > On the face of it this should be doable in the website code but > evidently Daniel James is the only one who really understands how this > works in the code and he is no longer active in Boost. So if someone > else who understands the website code and PHP could do this it would be > appreciated, since I think it will be valuable telling end-users whether > a Boost library is usable at the C++ compiler level they are using. > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

8 43

Providing a link to GitHub commit from documentation
by pbristow＠hetp.u-net.com 19 Mar '21

19 Mar '21

I've been considering adding commit hash info to some documentation made using the Quickbook/Boostbook/Docbook/b2/bjam toolchain Using git command line git log or ls-remote I can show the necessary hex digit string: commit 5609fa86e37e1b0eae6466065ba6c8eb3ac0ab2f (HEAD -> refactor1) (It would be useful to have the local commit (rather than remote) so that the generated documentation including this has can be pushed up to remote). Paul@hetpD MINGW64 /i/boost/libs/quan/doc (refactor1) $ git log -n1 HEAD > commit.txt That contains commit 5609fa86e37e1b0eae6466065ba6c8eb3ac0ab2f Author: pabristow <pbristow(a)hetp.u-net.com> Date: Fri Mar 19 15:46:45 2021 +0000 Generated super new version. So this gets this info into a file, but I have yet to see how to get this into the Quickbook or ? during the b2 build. I note that the Boost documentation headers provide this information in the form a link like displayed as d57d645009 with contents https://github.com/boostorg/boost/commit/d57d6450098300343c6fe3a22129791524… but I don't know how this works. Has anyone done anything like this? Suggestions most welcome. Paul

4 4

Feedback on GSoC'21 project proposal
by Krushnal Patel 19 Mar '21

19 Mar '21

Hi, I am applying for the project Boost.XML. I have completed the competency test and the next step being proposal feedback from mentors, I have made a draft proposal. https://docs.google.com/document/d/1Bvno6ifHjo8EdMRuzFqCk9AEB5IgAxf2ag4xdc4… As this is a new library, I have not been able to add much in the 'Project Proposal' details except the bare minimum details. Mentors please have a look at it and let me know what you think. Should I make additions, remove or edit some things? -- Awaiting your feedback, Krushnal Patel http://krushnal.me/

2 1

(no subject)
by Sakshi Singh 19 Mar '21

19 Mar '21

Hello Sir/Mam I'm Sakshi Singh Dangi from India l'm interested in one of your project bit I don't know what to do regarding application process please guide me.

1 0

[GSoC'21] Boost.Math : FFT Utilities PROJECT 1 Guidance
by Tushar k 19 Mar '21

19 Mar '21

Hello, I am Tushar Khandelwal from BITS Pilani 2019 batch, I am working with C++ for the past 2 years so I have a decent understanding of C++. In the past few days, I went through different boost libraries and different project ideas. So, I liked one of the projects of Boost.Math library: FFT Utilities, I have studied Fast Fourier Transform a few months back in my university course signals and system, also I have read many different articles and videos related to this beautiful concept. I have some doubts related to it like what exactly are your expectations from this project? how should I proceed? So I request a potential mentor of this project Christopher Kormanyos or others to please guide me. thanks! Looking forward to this open-source project in GSoC'21. With regards Tushar Khandelwal

3 2

Re: [boost] [release] 1.76.0 post-beta merges
by Glen Fernandes 18 Mar '21

18 Mar '21

John Maddock wrote: > I've had a request to merge these new Boost.Config feature > checks to release as Serialization depends on them: > https://github.com/boostorg/config/pull/369 > Also related to Serialization, this bugfix for BOOST_HAS_HASH should > probably go in: https://github.com/boostorg/config/pull/374. OK to merge both. Glen

1 0

[asio] [regex] 1.76.0 beta 1 compilation failure
by Scott Determan 18 Mar '21

18 Mar '21

There appears to be a problem compiling a program that includes both asio and regex in 1.76.0 beta 1. The following program fails to compile: ``` #include <boost/asio.hpp> #include <boost/regex.hpp> int main(int argc, char** argv) { return 0; } ``` The error is: ``` /home/swd/projs/common/boost_1_76_0_b1/boost/regex/v5/match_flags.hpp:38:14: error: multiple definition of ‘enum boost::regex_constants::_match_flags’ 38 | typedef enum _match_flags | ^~~~~~~~~~~~ In file included from /home/swd/projs/common/boost_1_76_0_b1/boost/asio/detail/regex_fwd.hpp:21, from /home/swd/projs/common/boost_1_76_0_b1/boost/asio/read_until.hpp:23, from /home/swd/projs/common/boost_1_76_0_b1/boost/asio.hpp:146, from ../src/main.cpp:2: /home/swd/projs/common/boost_1_76_0_b1/boost/regex/v4/match_flags.hpp:38:14: note: previous definition here 38 | typedef enum _match_flags ```

4 4

(GSoC '21) uBlas Project 2/3 Guidance
by Laxman 18 Mar '21

18 Mar '21

Hi, I, Laxman Desai, am interested in ublas Project 2 and 3. I’ve built a few C++ libraries before (for personal use) and I am familiar with C++17, MATLAB, TensorFlow, NumPy and Pandas to a good extent. I am currently learning R. I also have a good mathematical background, especially in Linear Algebra. I have currently completed the Competency Test for uBlas, and would request the mentors: David Bellot, Cem Bassoy or Amit Singh to guide me further for Project 2: creating new matrix and vector types and Project 3: Finalize Dataframe Implementation. Project 2: I dont understand what experimental templates and ublas::experimental::matrix means. I although have a strong feeling that it just refers to the tensor implementation of the same. I haven’t used uBlas tensor_core before, so could a mentor explain further (a basic intuition of the improvement, and the workflow for this project)? I would also appreciate more information on submatrix, and its implementation! To my understanding, it is to solve the problem that C++ doesn’t allow overloading of the colon operator. Project 3: I also am interested in project 3 (Finalising the DataFrames Implementation), and am currently exploring the available features. I have been using Pandas for a while now, and recently learnt R. “Finalize and productionize” seemed a bit vague to me, could I get more information on what all the current implementation is lacking (except for documentation)? I would also like to know if the mentors have a shortlist of features to add in mind? Any feedback on this would be greatly appreciated. Kind Regards, Laxman Desai Mail: desai.laxman2001(a)gmail.com

1 0

SVN/Trac account settings not accessible
by Andrey Semashev 17 Mar '21

17 Mar '21

Hi, It looks like SVN/Trac manager is no longer working. Is there a way to change account password?

1 1

Remove obsolete Coding Guidelines for Integral Constant Expressions
by Nikita Kniazev 17 Mar '21

17 Mar '21

Boost Library Requirements and Guidelines has a page https://www.boost.org/development/int_const_guidelines.html which contains highly outdated information. I think the guideline no longer applies and should be simply removed.

1 0

[GSoC'21] Seeking Further Guidance for Project3:Finalize Dataframe Implementation (Boost.uBlas: Matrix and Tensor Computations)
by Kowndinya Renduchintala 17 Mar '21

17 Mar '21

Hi Community! I am Kowndinya Renduchintala, a Second Year Undergraduate majoring in Computer Science and Engineering at Indian Institute of Technology Bombay. I am completely new to Open Source Software Development. Having worked on C++ extensively for the last two years of my Undergraduate studies, I consider myself a proficient C++ programmer. I also had a great amount of exposure in Math, specifically in Linear Algebra and Calculus. This led me to do more work related to them and I started working in the field Data Science where I have largely used Python’s numpy and pandas libraries, also MATLAB in some cases. I am very much interested in developing equivalent capabilities of above mentioned libraries in C++ too! I have gone through the Project Description on the GSoC’21 Ideas Page, and I am highly delighted to see that “Project:3 Finalize Dataframe Implementation” (in Matrix and Tensor Computation category), matches my interests to a very large extent. I am also ready to spend 40-50 hours per week for the completion of the project, thereby helping in productionizing the code by the end of the GSoC’21. But I have some questions left out in my mind after reading the “Project Description” and the “Competency Test” following it. The description says- “add a collection of free form functions, modern data analysis procedures (as found in R tidyverse, in Python pandas/numpy, and in many other packages)”. 1. Do the mentor(s) have some preconceived “list” of the sort of functions to be implemented, or am I expected to include the details of “my” ideas in the project proposal that I submit to Google starting from Mar29 to Apr13? 2. Is the Competency Test(providing matrix and vector C++17 implementation similar to MATLAB syntax) meant for giving us a taste for how the work in actual project is going to look like? If it is the case, then I am highly interested to work on such things/ similar things for that matter. I request David Bellot(The Potential Mentor as per the Wiki page) or any one else who is involved with the above project to please guide me further. After clarifying above two questions, I can straight away get into business and start the work, try to make a list of deliverables and probably ask more “technical” questions that I have in the code base, in my next mail. Looking forward to collaborate with Boost.uBlas and successfully complete my first Open Source Software Development project at GSoC’21 in my most favourite programming language!!! Regards Kowndinya Renduchintala rharisrikowndinya333(a)gmail.com Sent from [1]Mail for Windows 10 References 1. https://go.microsoft.com/fwlink/?LinkId=550986

1 0

[sort] How does pdq-sort allocated memory?
by Viktor Sehr 17 Mar '21

17 Mar '21

According to the documentation boost::pdq_sort uses Log N additional memory. Assuming this memory is allocated via new, is it possible to pass an allocator, or even better, a pre-reserved std::vector<T> to the algorithm in order to avoid allocation? I could not find anything in the documentation about this. /VIktor

1 0

Confusion regarding projects
by Ameya Chawla 17 Mar '21

17 Mar '21

Respected sir/madam I want to contribute to Boost C++ libraries , but i am confused that do I have to contribute to all the 3 projects mentioned in Boost.uBlas <https://github.com/boostorg/ublas>: Matrix and Tensor Computations or I can contribute to any one of them .and competency test is for project 2 only or for all 3 projects ? https://github.com/CGAL/cgal/wiki/Project-Ideas Thank you

1 0

Confusion regarding projects
by Ameya Chawla 17 Mar '21

17 Mar '21

Respected sir/madam I want to contribute to Boost C++ libraries , but i am confused that do I have to contribute to all the 3 projects mentioned or I can contribute to any one of them .and competency test is for project 2 only or for all 3 projects ? https://github.com/CGAL/cgal/wiki/Project-Ideas Thank you

1 0

[release] Boost 1.76.0 beta 1 released
by Marshall Clow 16 Mar '21

16 Mar '21

Boost release 1.76.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.76.0.beta1/source/> The SHA256 checksums are as follows: 39eecd9672e78b95c8e3fdec1430a63788d528a66d3c8799c4639238e5d785bd boost_1_76_0_b1.7z c32edd34f767dd4bb67b86f76ebf58cf76822a5993a9b434c028b2dd08cfeefc boost_1_76_0_b1.zip 3ec1f92fa0a159b7073e39dd88f527a55d1f35e8986a3c560f202a75bdb8d584 boost_1_76_0_b1.tar.gz eb098d6d5352e10b17a3c49d2927ed61f09b6544f7c534627de35dfa2560fe20 boost_1_76_0_b1.tar.bz2 For details of what's in the release, see <https://www.boost.org/users/history/version_1_76_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

1 0

Introduction-Tushar Khandelwal
by Tushar k 16 Mar '21

16 Mar '21

Hi, I am Tushar Khandelwal from BITS Pilani 2019 Batch, I have a decent understanding of C++, I have been practicing C++ for the past 2 years, I am proficient in data structures and algorithms, I am new to open source and would love to contribute to this organization. How should I get started?

1 0

Headers only or .o
by Damian Vicino 15 Mar '21

15 Mar '21

Hi, I was reading the development section of the docs: https://www.boost.org/development/index.html And, I noticed there was nothing in the development guidelines about when to implement as headers-only vs built library. I got my own ideas of why most libraries are headers-only. But, I was wondering if someone with the historical context (someone who was here when those first libraries were developed) can share how boost got into the current shape and what new library developers should look into when deciding to go headers-only or not. I appreciate any anecdotes, guidelines, tradeoffs, thumb rules, comments on the topic. I would love to collect as much as possible here in this thread and write something to post in the development doc section in the website for future reference. Best, Damian

4 4

[Describe] Review - Part 2: Class types
by Andrzej Krzemienski 15 Mar '21

15 Mar '21

Hi Everyone, Some feedback from playing with Boost.Describe for class types. 1. As others pointed out, it is confusing that BOOST_DESCRIBE_STRUCT() and BOOST_DESCRIBE_CLASS() have such close names, but their interface and requirements are so different. Maybe rename the latter to BOOST_DESCRIBE_THIS_CLASS()? 2. Base class subobjects are in some applications treated equivalently to member subobject; this is why I found it surprising that I cannot get the names of base class subobjects. But I guess there are implementation difficulties. Bases can be qualified names. 3. As with enums, _public_member_descriptor_fn in global namespace is UB or invalid program as per http://eel.is/c++draft/lex.name#3.2. 4. As others pointed out, the part of the interface that uses enum modifiers is not intuitive. I think that after a while it starts to make sense: you decide on your use case (like doing RPC), form your enum bitmask, and then pass it everywhere. It became more-less clear to me only after I had a look at the implementation of member_filter: https://github.com/pdimov/describe/blob/develop/include/boost/describe/memb… Maybe it makes sense to expose this in the docs. 5. Modifier mod_inherited is great for flattening the inheritance structure: struct X { int a; }; struct Y : X { int b; }; struct Z : Y { int c; }; BOOST_DESCRIBE_STRUCT(X, (), (a)); BOOST_DESCRIBE_STRUCT(Y, (X), (b)); BOOST_DESCRIBE_STRUCT(Z, (Y), (c)); int main() { namespace desc = boost::describe; using namespace std::literals::string_literals; constexpr auto mod = static_cast<desc::modifiers>(desc::mod_public | desc::mod_inherited); using L = desc::describe_members<Z, mod>; assert((boost::mp11::mp_at_c<L, 0>::name == "a"s)); assert((boost::mp11::mp_at_c<L, 1>::name == "b"s)); assert((boost::mp11::mp_at_c<L, 2>::name == "c"s)); } But it is not obvious at first. I recommend that the docs provide an example like this. It even works when base classes have members with same names: struct X { int a; }; struct Y { int a; }; struct Z : X, Y { int b; }; BOOST_DESCRIBE_STRUCT(X, (), (a)); BOOST_DESCRIBE_STRUCT(Y, (), (a)); BOOST_DESCRIBE_STRUCT(Z, (X, Y), (b)); int main() { constexpr auto mod = static_cast<describe::modifiers>(describe::mod_public | describe::mod_inherited); using L = describe::describe_members<Z, mod>; Z z = {{{3}}, {{6}}, {9}}; assert((z.*mp_at_c<L, 0>::pointer == 3)); assert((z.*mp_at_c<L, 1>::pointer == 6)); assert((z.*mp_at_c<L, 2>::pointer == 9)); } 5. What is the use case for modifier mod_hidden? I cannot think of any situation where I would need it. 6. Regarding the overloaded functions, I am no expert in preprocessor metaprogramming, but maybe if there was a way to provide function signatures along the name, you would have enough information to form the pointers. Something like: struct X { void f(int){} void f(void*){} }; BOOST_DESCRIBE_STRUCT(X, (), ( SIGNATURE(void f(int)), SIGNATURE(void f(void*)) ); 7. Modifier mod_virtual works unintuitively. It does not affect the filtering in describe_bases<>. It is only used for decorating the list elements. Maybe the docs should be more explicit about what it is used for. Again, is there a use case for this? Regards, &rzej;

4 4

GSoC'21 boostorg timeline
by Krushnal Patel 15 Mar '21

15 Mar '21

Hi, I wanted to inquire about the GSoC'21 timeline specific to boostorg. I have gone over the GSoC'21 timeline but are there any specifics decided by boost regarding project selection, pre-proposal submission, proposal overview, programming competency test submission, etc? I am asking this question because as I was going over last years' mailing list I found a post where 'pre-proposal submission' was discussed so I started researching more about any timeline released specifically by boost but did not find any. Thanks in advance. Krushnal Patel, http://krushnal.me/

2 1

Requirement of mentorship for Generic Image Library project
by Aditya Tiwari 15 Mar '21

15 Mar '21

Hello there, I am Aditya Tiwari, a GSoC aspirant. I am interested in contributing to the Boost C++ library on the project "*Generic Image Library*". The knowledge requirement for this project is C++ and understanding of basic image processing algorithms, and I have a good knowledge of these two. I have been coding in C++ for over two years, with prior experience working with Boost libraries and working on projects related to image processing for over 1 year. I have read the problem statement and under GIL there's a project 2 about implementing image processing algorithms and in that list I know quite a bunch of algorithms. Also the project 1 under GIL, is quite a confusing task for me like do we have to add more and efficient algorithms here or something else? It would be very helpful if you can guide me through this project. I am open to any suggestions and I shall proceed with the task upon your acknowledgement. Regards, Aditya

2 1

Re: [boost] [release] Boost 1.76.0 Beta 1 Release Candidate 1: fixed std::allocator deprecation-warning
by Löw, Tobias (STEAG Energy Services GmbH) 15 Mar '21

15 Mar '21

Hi, I've made a fix for the deprecation-warning: boost\unordered\detail\implementation.hpp(1452,7): warning C4996: 'std::allocator<T>::is_always_equal': warning STL4010: Various members of std::allocator are deprecated in C++17. Use std::allocator_traits instead of accessing these members directly. You can define _SILENCE_CXX17_OLD_ALLOCATOR_MEMBERS_DEPRECATION_WARNING or _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have received this warning. The PR is here: https://github.com/boostorg/unordered/pull/21 Tobias

1 0

[release] Boost 1.76.0 Beta 1 Release Candidate 2
by Marshall Clow 13 Mar '21

13 Mar '21

The second release candidates for the 1.76.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.76.0.beta1/source/> The SHA256 checksums are as follows: c32edd34f767dd4bb67b86f76ebf58cf76822a5993a9b434c028b2dd08cfeefc boost_1_76_0_b1_rc2.zip eb098d6d5352e10b17a3c49d2927ed61f09b6544f7c534627de35dfa2560fe20 boost_1_76_0_b1_rc2.tar.bz2 39eecd9672e78b95c8e3fdec1430a63788d528a66d3c8799c4639238e5d785bd boost_1_76_0_b1_rc2.7z 3ec1f92fa0a159b7073e39dd88f527a55d1f35e8986a3c560f202a75bdb8d584 boost_1_76_0_b1_rc2.tar.gz The only changes from RC1 is an update to Boost.Interprocess, which was failing to compile on Mac OS X. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

2 2

Master branch now closed for 1.76.0 beta release
by Marshall Clow 13 Mar '21

13 Mar '21

Please do not make any commits to the master branch. — Marshall

2 2

Re: [boost] FFT proposal for gsoc 2021
by Janek Kozicki 13 Mar '21

13 Mar '21

> Strongly and beneficially Influence that. But we still need > To adhere to all formal application Steps A note regarding these formal steps: https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code%3A-2021 https://lists.boost.org/Archives/boost/2021/02/250876.php https://www.boost.org/users/faq.html > On the board. I can do 1 mentor of Either quad double or FFT. Yeah, both of them are very useful for me. If we make FFT this year, we can hope for quad-double next year :-) best regards Janek Christopher Kormanyos said: (by the date of Fri, 12 Mar 2021 16:00:38 +0100) > We still need to adhere to the > Formal application process > And we should have our dialog > On the board. I can do 1 mentor of > Either quad double or FFT. > > Having your own idea and a > Working model is a tremendous > Advantage in the application > Process and is likely to very > Strongly and beneficially > Influence that. But we still need > To adhere to all formal application > Steps > > Kindest regards, Chris > > Sent from my iPhone > > > On 12. Mar 2021, at 07:26, Eduardo Quintana <eduardo.quintana(a)pm.me> wrote: > > > > Dear Christopher, > > > > I am thrilled to hear from you! Thank you for offering mentorship for this > > project. I look forward to start working on it. > > > > Best regards, > > Eduardo > > > >> On Thu, Mar 11, 2021 at 06:55:37PM +0000, Christopher Kormanyos wrote: > >> > >> <html><head></head><body><div class="ydpad5c413ayahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div></div> > >> <div dir="ltr" data-setdir="false"><div>> Hi Boost community,<br><div>> I've been working on a C++ templated library</div><div>> for Fast Fourier Transforms</div><div><br></div><div>> ...<br></div></div><div dir="ltr" data-setdir="false"><span>> Is there anyone interested in supervising this</span></div><div dir="ltr" data-setdir="false"><span>> project? Any opinions?</span></div><div dir="ltr" data-setdir="false"><span><br></span></div><div dir="ltr" data-setdir="false"><span>Thank you for your interest and query.<br></span></div><div dir="ltr" data-setdir="false"><span><br></span></div><div dir="ltr" data-setdir="false"><span>Yes. I think I am interested and potentially qualified</span></div><div dir="ltr" data-setdir="false"><span>as 5 time GSoC mentor in Multiprecision and Math.</span></div><div dir="ltr" data-setdir="false"><span><br></span></div><div dir="ltr" data-setdir="false"><span>The plan seems good, start with header only</span></div><div dir="ltr" data-setdir="false"><span>simple implementation and increase complexity</span></div><div dir="ltr" data-setdir="false"><span>and efficiency as time allows.</span></div><div dir="ltr" data-setdir="false"><span><br></span></div><div dir="ltr" data-setdir="false"><span>This project would fill a present gap and wish list</span></div><div dir="ltr" data-setdir="false"><span>entry in Math/Multirpecision for those unable/unwilling</span></div><div dir="ltr" data-setdir="false"><span>to include FFTW.</span></div><div dir="ltr" data-setdir="false"><span><br></span></div><div dir="ltr" data-setdir="false"><span>I will write a little project description at rthe relevant</span></div><div dir="ltr" data-setdir="false"><span>page, link will follow...<br></span></div><div dir="ltr" data-setdir="false"><span><br></span></div><div dir="ltr" data-setdir="false"><span>Feel free to continue this thread, at the moment, i'm</span></div><div dir="ltr" data-setdir="false"><span>too busy to put down all my thoughts...<br></span></div><div dir="ltr" data-setdir="false"><span><br></span></div><div dir="ltr" data-setdir="false"><span>Kind regards, Christopher</span><br></div></div><div><br></div> > >> > >> </div><div id="yahoo_quoted_5520563993" class="yahoo_quoted"> > >> <div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;"> > >> > >> <div> > >> On Thursday, March 11, 2021, 10:55:29 AM GMT+1, Eduardo Quintana via Boost <boost(a)lists.boost.org> wrote: > >> </div> > >> <div><br></div> > >> <div><br></div> > >> <div>Hi Boost community,<br><br>I've been working on a C++ templated library for Fast Fourier Transforms,<br>https://github.com/Lagrang3/fftx.<br>Templated because some FFT algorithms are algebraic-field independent, eg. you<br>could FFT an array of N matrices provided a Nth matrix-root-of-unity is given.<br>As a result you could have a single algorithm for a variety of underlying, eg.<br>`std::complex<float>`, `std::complex<double>`, `std::complex<long double>`,<br>`boost::math::quaternion`, finite field types (this would yield the "Number<br>theoretic transform" <a href="https://cp-algorithms.com/algebra/fft.html#toc-tgt-6" target="_blank">https://cp-algorithms.com/algebra/fft.html#toc-tgt-6</a>).<br><br>I would like to improve this library during the GSOC 2021, as a proposal for<br>inclusion inside Boost.Math or Boost.Algorithms.<br><br>Is there anyone interested in supervising this project? Any opinions?<br><br>Best regards,<br>Eduardo Quintana<br><br>_______________________________________________<br>Unsubscribe & other changes: <a href="http://lists.boost.org/mailman/listinfo.cgi/boost" target="_blank">http://lists.boost.org/mailman/listinfo.cgi/boost</a><br></div> > >> </div> > >> </div></body></html> > > <publickey - eduardo.quintana(a)pm.me - 341e5416.asc> > -- -- Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. Gdańsk University of Technology Faculty of Applied Physics and Mathematics Department of Theoretical Physics and Quantum Information -- http://yade-dem.org/ http://pg.edu.pl/jkozicki (click English flag on top right)

1 0

[GIL] 2D Convolution/Correlation Proposal for gsoc 2021
by Gaurav kumar 12 Mar '21

12 Mar '21

Hi, I am Gaurav Kumar; I have been working on the Boost.GIL library for the past month. I would like to work on the 2D convolution/Correlation project. The ideas for the project are as follows: 1. Separable Kernels <http://www.dspguide.com/ch24/3.htm>: Most of the standard kernels (e.g. Gaussian, Sobel) can be separated into 2 or more 1D filters. For a N x N kernel, separating it into two 1D filters, the number of computations required would now be proportional to 2*N instead of N*N for the naive implementation. This implementation would also favor code reusability as this would only require a kernel separating function and driver code for a group of 1D filters. 2. Generic Implementation for 2D convolution: There are more generic kernels that are non-separable (e.g. Laplacian operator). In this case, the naive approach has already been implemented. The main task would be to provide the same set of functions as in the 1D convolution/correlation implementation. One potential idea for optimization of 2D convolution is to use the Im2col <https://www.programmersought.com/article/6306124604/> operation, in which the input image is converted into a row of column vectors, where each column vector represents an image block for which convolution/correlation operation is to be performed. The kernel can also be flattened out in a similar manner, resulting in a 1D array. This results in the convolution operation being reduced to matrix multiplication, which can be handled efficiently by BLAS libraries <https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprograms> ( Boost.uBLAS ). Please share any suggestions you would have, related to the ideas presented above, or regarding 2D convolutions in general. I am looking for a mentor to guide me through this project. Best Regards, Gaurav Kumar Github handle: https://github.com/gkumar28

2 1

[release] Boost 1.76.0 Beta 1 Release Candidate 1
by Marshall Clow 12 Mar '21

12 Mar '21

The first release candidates for the 1.76.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.76.0.beta1/source/> The SHA256 checksums are as follows: a222d325cd3c9f66951ec9026eca6ff6f48dd563c9a025911d598d2aca8770ce boost_1_76_0_b1_rc1.tar.bz2 6b90b510a3de38fc30a071ac798da37545fb60a1d6b21aed1130b47c9c598977 boost_1_76_0_b1_rc1.zip b01627bd9ce934b092037da81696bb4482a44e6a31c8791dbed82eafe04b69fa boost_1_76_0_b1_rc1.tar.gz dbef57adbab1d4395d14000f0a2420fc82f87476e10d48359ceff7125a74b77a boost_1_76_0_b1_rc1.7z As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

7 10

Endorsement, review manager sought for Boost.Mysql
by Ruben Perez 12 Mar '21

12 Mar '21

Hi all, I would like to propose a MySQL client library for Boost (under the original name of Boost.Mysql). It is a full implementation of the MySQL client protocol, based on Boost.Asio. It requires C++11. The library is at https://github.com/anarthal/mysql and the documentation is at https://anarthal.github.io/mysql/. Examples under https://anarthal.github.io/mysql/mysql/examples.html. The purpose of this library is to provide a low-level building block for applications or other libraries to interact with MySQL, in the same way Boost.Beast provides a way to interact with HTTP. It complies with Boost.Asio universal asynchronous model, and provides the usual sync and async overloads for every network operation. Some notes: - The scope of this library is limited to MySQL. Its value proposition is implementing the client protocol in an Asio-compliant way. Supporting any database other than MySQL is not in scope of this library. - This library does NOT make use of MySQL libmysqlclient C API. It provides a from-the-ground-up implementation of the MySQL client protocol. Features: - Text queries and server-side prepared statements. - Sync and async functions, following Boost.Asio's universal async model. You may use callbacks, Boost coroutines, futures, C++20 coroutines, or any completion handler that Asio adds support for. - Can be used with any Stream including TCP sockets, UNIX sockets and Boost.Beast TCP streams. - Supports MySQL 5.x, MySQL 8.x and MariaDB.

10 17

[Boost][Describe] Has been ACCEPTED into Boost
by Richard Hodges 12 Mar '21

12 Mar '21

Dear all, I am pleased to announce that we have received 13 high quality reviews. There has been no dissent, with every reviewer recommending that Describe be accepted. Reviews that were sent to me privately have been forward to Peter for consideration. If you have submitted a review and I have not responded privately to thank you, then please accept my apology for this oversight. Thank you everyone for taking some of your valuable time to contribute. -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

3 2

[interprocess][managed_shared_memory] Memory allocation of managed shared memories
by Grimm, Matthias 12 Mar '21

12 Mar '21

Hi, I have a question regarding the interprocess library and the use of shared memories. When creating a boost::interprocess::managed_shared_memory it seems to be necessary to take some additional space into account. In my case the following approach works well: managed_shm = new ip::managed_shared_memory(ip::create_only, "shm_id", (vec_elems + 110) * (number_of_samples + 1)); Following this it seems to be necessary to always have one additional element. If I remove the additional element (vec_elems + 110) * (number_of_samples) an exception is thrown: boost::interprocess::bad_alloc. This is also the case if I change to (vec_elems) * (number_of_samples + 1) Does anybody know why it is necessary to have this additional space allocated? What is the exact minimum size to avoid the exception? The additional memory may become a problem if the size of the vector elements is large. Attached you'll find some example code. Any help on this topic would be appreciated.

1 0

GSoC'21
by Manan Sharma 12 Mar '21

12 Mar '21

Hey, My name is Manan Sharma, I went through the project ideas for the GSoC'21 and the Multiprecision project really caught my eye. So I would like to contribute to this project but do not know where to start. I have basic knowledge of C++ like Template Programming. So I would appreciate it if anyone could tell me how to get started. Looking forward to contributing to the project. Yours sincerely, Manan Sharma Phone No.: +91 9711306818 Email Id.: manan180796(a)gmail.com

2 1

Queries regarding Contributing to boost open source library
by Tirtharaj Sen 12 Mar '21

12 Mar '21

Hello, I'm Tirtharaj Sen I wanted to know that I will start to contribute to boost open source library from today , so will can I make proposals for GSOC 2021 to the organisation or am I a bit late to start to contribute. I would also like to mention that I want to be associated with the organisation even after the GSOC is over. So does it require a 3 months of contribution history? Will be obliged if I get help from yours's side Thank you

2 1

Does anyone use mp11 with VS2013?
by Peter Dimov 11 Mar '21

11 Mar '21

Does anyone here use mp11 with Visual Studio 2013? (msvc-12.0) 2013 kind of supports C++11 but only barely, and I keep bumping into its bugs and limitations, so I'm considering dropping it and making 2015 the minimum requirement.

1 0

[Boost] [Describe] library submission - last call for reviews from the community
by Richard Hodges 11 Mar '21

11 Mar '21

A friendly reminder that the review period for [Boost.Describe] will finish at the end of tomorrow - 10th March 2021 We've had some excellent feedback already, and would value more. If you can spare a few hours of your valuable time, please consider reviewing this neat little library and posing your results on this mailing list. The invitation is repeated below: The Boost formal review of the Describe starts Monday, taking place from March 1st, 2021 to March 10th, 2021 (inclusive). The library is authored by Peter Dimov. Documentation: https://pdimov.github.io/describe/doc/html/describe.html Source: https://github.com/pdimov/describe The library provides a simple means of providing reflection for structures and enums in C++. The documentation contains a number of common motivating examples, including: - A universal print function https://pdimov.github.io/describe/doc/html/describe.html#example_print_func… - JSON serialisation https://pdimov.github.io/describe/doc/html/describe.html#example_to_json Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including Describe 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. Richard Hodges - review manager of the proposed Boost.Describe library Peter is often available in the CppLang Slack #boost channel should you require any clarification not covered by the documentation, as am I. Please submit your review to the Boost mailing list: boost(a)lists.boost.org -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

3 6

[release] Reminder about 1.75.0 release notes
by Marshall Clow 11 Mar '21

11 Mar '21

The master branch is closing on Wednesday for the 1.75.0 release. If you have information that should go into the release notes, now’s the time to add it. Create a PR against https://github.com/boostorg/website/blob/master/feed/history/boost_1_75_0.q… <https://github.com/boostorg/website/blob/master/feed/history/boost_1_75_0.q…> — Marshall

2 3

[release] Release notes for 1.76.0
by Marshall Clow 11 Mar '21

11 Mar '21

If you have information that should go into the release notes, now’s a good time to add it. Create a PR against https://github.com/boostorg/website/blob/master/feed/history/boost_1_76_0.q… — Marshall

1 0

[Geometry] Proposing a project idea for GSOC 2021
by Siddharth Kumar 11 Mar '21

11 Mar '21

Hey, This is Siddharth Kumar. I have been working on the Boost.Geometry library for the past 2-3 months. I would like to propose a project idea about adding features for 3d-geometries, especially polyhedral surfaces which includes:- 1. Defining a geometry for the polyhedral surfaces. 2. Read and write features for the polyhedral surfaces. 3. Defining functions for the properties of polyhedral surfaces like volume, surface area, etc. This implementation will help in the direct use of the geometry in such algorithms, which are not yet implemented for the 3d-geometries or don’t provide compatible results when working with 3d-shapes, as they give points as an output rather than taking a geometry. For example- The convex hull <https://github.com/boostorg/geometry/issues/683> doesn’t handle 3d geometries correctly, because there is no 3d geometry defined that can handle the result of the algorithm. I have already submitted a PR <https://github.com/boostorg/geometry/pull/789> (yet to be merged), which defines the geometry for polyhedral surfaces, and also includes wkt read and write features, I am willing to work on other properties of the polyhedral surfaces as a project for GSOC 2021. I am looking for a mentor who is willing to guide me in this project. Thanks

2 2

[Describe] Andrzej's review.
by Andrzej Krzemienski 10 Mar '21

10 Mar '21

Hi Everyone, This is my review of the Boost.Describe library. I recommend that the library should be **ACCEPTED** into Boost. The goal of the library is clearly specified, and addresses real world needs. The examples (JSON serialization, printing) are convincing, and the number of reviews saying "I needed it for a while" reassure that it will be useful. The library is well designed. I mean the separation into macros declaring the "reflection lsts", and then functions operating on those lists. The documentation, in connection with the clear design, makes it easy to learn and use the library. The only issues I had was with the modifiers enum: I had to look into the implementation to understand how some values work. Regarding the implementation, I only had a superficial look. One thing I observed is that the implementation is very short! When I tried to combine all headers into one, in order to test it on WandBox, I discovered that it is less than 600 lines. You can see it here: https://wandbox.org/permlink/rkAtPCbAsqNzVRMV The only issue I have is the names that start with the underscore that can potentially end up in the global namespace, which by my reading of the C++ Standard is UB. I have spent a couple of hours testing toy examples, reading the docs, and looking at the implementation. I used GCC 9.2.0 on MinGW and GCC 10.1.0 on WandBox. All worked fine. Regarding my previous concerns about the "N+1" problem (an overlap with other libraries), I no longer have it. Boost.Describe is for class and enum authors to offer a reflection information for whoever wants it. A library like Boost.Fusion is for working with fusion sequences. Only as convenience, it provides a way to adapt a user defined class as a fusion sequence, but if it wants, it can use Boost.Describe lists as an alternative way of providing the adaptation. My two real-life use cases for a reflection like this was: 1. Adapting aggregates for Boost.Spirit. It looks like even Boost.FPR would do. 2. Printing and implementing swap() and hash() for my types. So far I had to do it manually, so I am looking forward to having this library in Boost. Finally, I would like to thank Peter for writing and sharing this library. Regards, &rzej;

1 0

Boost accepted in Google Summer of Code 2021
by David Bellot 10 Mar '21

10 Mar '21

We're in again! https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code%3A-2021 David

2 1

[Boost] [Describe] Review Reminder
by Richard Hodges 10 Mar '21

10 Mar '21

A friendly reminder that the review period for [Boost.Describe] is half way through. We've had some excellent feedback already, and would value more. If you can spare a few hours of your valuable time, please consider reviewing this neat little library and posing your results on this mailing list. The invitation is repeated below: The Boost formal review of the Describe starts Monday, taking place from March 1st, 2021 to March 10th, 2021 (inclusive). The library is authored by Peter Dimov. Documentation: https://pdimov.github.io/describe/doc/html/describe.html Source: https://github.com/pdimov/describe The library provides a simple means of providing reflection for structures and enums in C++. The documentation contains a number of common motivating examples, including: - A universal print function https://pdimov.github.io/describe/doc/html/describe.html#example_print_func… - JSON serialisation https://pdimov.github.io/describe/doc/html/describe.html#example_to_json Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including Describe 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. Richard Hodges - review manager of the proposed Boost.Describe library Peter is often available in the CppLang Slack #boost channel should you require any clarification not covered by the documentation, as am I. -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

6 5

[Describe] Review - Part 1: Enumerators
by Andrzej Krzemienski 10 Mar '21

10 Mar '21

Hi Everyone, This is part one of my review of Boost.Describe. I will focus only on dealing with enumerators. Working with C++ enumerations is harder than one might think, because they are not what many people believe. They are just a bunch of integral constants and an integral type. We can get things like this: enum Season { Spring = 1, Summer, Autumn, // British Fall = Autumn, // American Winter, }; struct Human { std::string name; Season born; }; int main() { Human h {}; inspect(h); } void inspect(Human h) { switch(h) { case Spring: case Summer: case Fall: case Winter: return; default: assert(false) } } I can trigger an assertion failure without even doing any cast, because enums can assume other values that those listed in the declaration. The low-level interface provided by Boost.Describe is able to manage all these aspects very nicely. If we call BOOST_DESCRIBE_ENUM on struct Season above, we will get a list of five elements and the user will have to decide what she wants to do with it. On the other hand, requesting that Boost.Describe should provide a higher level enum-to-string mapping seems to overlook the special rules of C++ enums. How do you want this function to behave if the input enum value is not found? What do you want the function to do if it finds more than one corresponding string? The interface of describe_enumerators<> is optimal. Macro BOOST_DESCRIBE_ENUM is redundant: BOOST_DESCRIBE_ENUM_CLASS can handle unscoped enumerations pretty well. Note that in C++11 you can use the qualified names of unscoped enumerators, like Season::Winter in the above example. After playing first with macros for describing structs, I was surprised that the syntax for describing enumerators doesn't use parentheses for the list of enumerators: BOOST_DESCRIBE_ENUM(X, (A, B, C)); // I somehow expected that to work. Describing enums from the global namespace introduces names starting with underscore (_enum_descriptor_fn) into global namespace. This is Undefined Behavior, and is likely to trigger some code sanitizers. Instead use an ugly name, like boost_describe_enum_descriptor_fn. I do not appreciate the BOOST_DEFINE_ macros for enumerations. We get as much as four of them, and neither is able to handle the use case that I consider basic, which I often have in my code: where I omit value zero and start from 1: struct Error { badSoething = 1, badSomethingElse, tooLongSomethng, ... }; So, I am not sure how many real life enums these macros cover. Regards, &rzej;

3 4

[release] Reminder: Master branch closing WEDNESDAY 3/10 for 1.76.0 beta release
by Marshall Clow 10 Mar '21

10 Mar '21

Calendar here: https://www.boost.org/development/ <https://www.boost.org/development/> — Marshall

2 1

Boost beast HTTP server
by Jupiter 09 Mar '21

09 Mar '21

Hi, I installed almost all boost libraries to a Ubuntu 18.04 machine to run services, but I could not find which Ubuntu boost package includes beast, I looked at Internet comments that the cmake seems only working for Windows, how can I build beast in Ubuntu if the beast is not available in any ubuntu boost packages? Also, appreciate links to download breast samples. Thank you very much. Kind regards, Jupiter

2 1

Re: [boost] [Boost] [Describe] library submission - last call for reviews from the community
by Samuel DEBIONNE 09 Mar '21

09 Mar '21

> Please provide in your review information you think is valuable to > understand your choice to ACCEPT or REJECT including Describe as a > Boost library. Please be explicit about your decision (ACCEPT or REJECT). ACCEPT! Thank you Peter for submitting this library. > Some other questions you might want to consider answering: > - What is your evaluation of the implementation? TBH, I did not look at the code much, I expect a lot of preprocessor machinery to generate the metadata. > - What is your evaluation of the documentation? Clean and to the point. Maybe the section "Describing Class Types" could be split in "Describing Class Types" and "Reflecting Class Types" (usage of the description)? Nitpick: the code snippets are missing syntax highlighting. > - What is your evaluation of the potential usefulness of the library? Definitely useful. I see a bright future for this library especially if it makes it to the standard. I am not sure how compatible it is with the C++ Reflection TS though. Baby steps is probably the right approach for such a complex feature... > - Did you try to use the library? With which compiler(s)? Did you > have any problems? GCC 9.3 on Linux. I am not sure if the examples are integrated to the build system yet but compiling them was a no-brainer. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? About two hours, playing with the examples and writing my owns. Like many previous reviewers, I got tricked with the modifiers of the class describer. The | operator might be a bit misleading because some modifiers (mod_function) actually reduce the scope of the description. Reflecting the name of the type would be a nice addition. I am not a big fan of the BOOST_DEFINE_*** macros -actually shouldn't they be BOOST_DESCRIBE_DEFINE_ENUM? But since we have definition macros for enums, for symmetry, how about definition macros for structures -Hana has BOOST_HANA_DEFINE_STRUCT? I wonder if "fixed enum" is a standard terminology? > - Are you knowledgeable about the problem domain? Just from a user perspective. I use Boost.Hana[1] to get some level of reflection on structures. This solution is more limited than the one proposed in Boost.Describe (e.g. does not support member functions out of the box). The scope of Boost.Hana is much larger though and reflection is more a side effect of the Struct concept than a goal of the library. I use Better Enums[2] to get reflection on enums. Magic Enum C++[3] is a more modern alternative. Both libraries offer more features out of the box (aka enum_to_string) but I understand that the purpose of Describe is to "establish a standard way of providing these reflection abilities" and the interface needs to remain minimal to be the common factor. I have a patched Boost.Serialization that supports generic serialization of Hana Struct, just to say that it's possible. Thanks, Samuel 1. https://www.boost.org/doc/libs/1_61_0/libs/hana/doc/html/group__group-Struc… 2. https://github.com/aantron/better-enums 3. https://github.com/Neargye/magic_enum

2 1

[concept_check] Fix issue #31 for Boost 1.76?
by Mateusz Loskot 09 Mar '21

09 Mar '21

Hi. Since VS 2019 16.9.0 is out and rolling, can we put a priority on fixing this issue? https://github.com/boostorg/concept_check/issues/31 IOW, could the maintainers decide which of the discussed fixes they prefer and what PR has chance to be merged promptly for Boost 1.76? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

New home for B2.
by René Ferdinand Rivera Morell 08 Mar '21

08 Mar '21

As some of you may have noticed, B2 has a new home outside the Boost organization at <https://www.bfgroup.xyz/b2/>. The goal of the move is to elevate B2 development above the constraints of the Boost structure. I.e. to make B2 not just the build system that Boost uses. The biggest change to make happen is that last week the B2 fork at < https://github.com/bfgroup/b2> became the base git repo of all existing B2 git repos. And hence it means that the git repo < https://github.com/boostorg/build> is now a fork. What does this mean going forward? This that will not change: * Boost will still get the build system from the same git repo as it does now. * The B2 documentation will still be included in the Boost releases. What will change (eventually), or has already changed: * Development has moved to the new B2 git repo. And hence PRs for B2 will need to be posted to the new repo. * The B2 mail list at < https://lists.boost.org/mailman/listinfo.cgi/boost-build> will be replaced by the GitHub discussion forums at < https://github.com/bfgroup/b2/discussions>. * The B2 version in Boost will be updated from the base git repo for releases of the B2 base only. I.e. a B2 release will get merged to the Boost develop branch. And from there to the master branch. * The Boost testing of B2 reported at < https://www.boost.org/development/tests/develop/developer/summary.html> will stop showing (and hence running) B2 tests.The testing has already moved to cloud CI. And expanded to cover more platforms than Boost usually tests. * The B2 web site at <https://boostorg.github.io/build/> will go away. * The issues at <https://github.com/boostorg/build/issues> will eventually go away (once I deal with enough of them). -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

2 2

[Describe] Clarification on the library scope
by Andrzej Krzemienski 08 Mar '21

08 Mar '21

Hi Everyone, First of all, I wanted to thank Peter for writing and sharing this library. A number of people already indicated it is useful, and I also have use cases that would be addressed by this library. I would lie to clarify if my understanding of the scope of this library is correct. From the discussion so far, I understood that the goal is to provide a low-level minimum building block that enables writing more elaborate libraries for providing type introspection. The library gives me the following guarantee: if a user used macro BOOST_DESCRIBE_STRUCT for some type T (and there are no ODR violations) than I can use `boost::describe::members` to see what those members are: their name, their type, and a pointer. If I want to use this data in a convenient way, I have to use another library atop of Boost.Describe. For instance, when I need to observe struct X as a tuple of references, I will write my own library, which: 1. Checks if Boost.PFR can figure it out automagically. If so, use this magic 2. If not, resort to Boost.Describe, and based on its interface, form a tuple of references. Did I capture it correctly? In that case, requesting high-level features in Boost.Describe is against its design goals. It is a low-level piece, not necessarily to be used directly. Regard, &rzej;

3 2

[Describe] Boost.Describe vs Boost.Fusion
by Andrzej Krzemienski 08 Mar '21

08 Mar '21

Hi Everyone (but mainly Peter), Boost.Spirit needs to have an index-based access to user defined types, as explained in the tutorial: https://www.boost.org/doc/libs/1_75_0/libs/spirit/doc/x3/html/spirit_x3/tut… Currently Boost.Spirit uses the interface of Boost.Fusion, and users are encouraged to use macros like BOOST_FUSION_ADAPT_STRUCT: https://www.boost.org/doc/libs/1_75_0/libs/fusion/doc/html/fusion/adapted/a… The first question is, can Boost.Describe's interface be plugged into Boost.Spirit? It is not that obvious to me for a couple of reasons. For instance, it would require an interface in Boost.Describe for answering the question, "has describe::members been specialized for type X"? The second question is, can is Boost.Describe capable of replacing the adapter macros in Boost.Fusion? For instance, Boost.Fusion allows the users to define and adapt a user defined type with one macro: https://www.boost.org/doc/libs/1_75_0/libs/fusion/doc/html/fusion/adapted/d… This is similar in concept to what macro BOOST_DEFINE_ENUM does for enums. What is the motivation behind allowing the definition of enums in this way but not classes (at least the aggregate classes). My general observation is that we have a number of libraries with overlapping goals: Boost.Describe, Boost.PFR, Boost.Fusion (the part for adapting UDTs) Maybe it is ok, but does it mean that there are so many incompatible use cases? Maybe there is a way to reduce this number. Regards, &rzej;

3 7

[Boost] [Describe] Review starts Monday 1st March 2021 - 10th March 2021
by Richard Hodges 08 Mar '21

08 Mar '21

The Boost formal review of the Describe starts Monday, taking place from March 1st, 2021 to March 10th, 2021 (inclusive). The library is authored by Peter Dimov. Documentation: https://pdimov.github.io/describe/doc/html/describe.html Source: https://github.com/pdimov/describe The library provides a simple means of providing reflection for structures and enums in C++. The documentation contains a number of common motivating examples, including: - A universal print function https://pdimov.github.io/describe/doc/html/describe.html#example_print_func… - JSON serialisation https://pdimov.github.io/describe/doc/html/describe.html#example_to_json Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including Describe 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. Richard Hodges - review manager of the proposed Boost.Describe library Peter is often available in the CppLang Slack #boost channel should you require any clarification not covered by the documentation, as am I. -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

9 19

[spirit] Custom error on rule level?
by Serguei TARASSOV 08 Mar '21

08 Mar '21

Hello, is it possible to have a custom error handler on the rule level (for every rule in the limit) ? Cannot find this point in docs/examples. I.e. when parsing following texts (// are inline comments): DO_JOB WITH not_a_opt1; // should raise "Option not_a_opt1 is unknown" DO_JOB WITH opt2 = 123; // should raise "Invalid value 123 for option opt2" Regards,

2 1

[build] Could not open a pull request
by Nikita Kniazev 05 Mar '21

05 Mar '21

It seems that forks of boostorg/build switched their parent automatically and I could not find a way to open a PR against boostorg/build. What is happening and how do I proceed?

6 8

boost.log's text_multifile_backend is not performant on windows - perhaps it should be documented?
by Nicholas Neumann 05 Mar '21

05 Mar '21

I recently moved a project to boost.log from a homemade logger. I had something like text_multifile_backend, so finding that as a drop-in replacement was awesome. Unfortunately, the performance when using text_multifile_backend on windows is really bad, because the repeated file close operations (one per log record) are unusually slow on windows. Repeatedly logging a string to the same file via text_multifile_backend results in throughput of about 200 log entries per second. Just to quickly prove it is unique to windows, I made a simple program that just opens, appends a single line, and then closes, an ofstream in a loop. On a high-end windows machine with nvme ssd, 1000 iterations takes 2600ms. On an older linux box with a sata ssd, the same takes 16ms. What do others think about adding a note in the documentation about this performance issue? It's bad enough that I think anyone on windows would want to avoid the backend. It's not the backend's "fault" at all; I could see some options for improving performance of the backend on windows, but they definitely complicate the simplicity of the current approach. (Side note - in googling the issue, other projects have been bitten - notably mercurial on windows - https://gregoryszorc.com/blog/2015/10/22/append-i/o-performance-on-windows/ )

5 27

[quickbook] Broken links generated in locally built docs
by Andrey Semashev 05 Mar '21

05 Mar '21

Hi, When I'm building QuickBook docs locally for Boost.Log, I'm seeing errors like the following in the end: Error: no ID for constraint linkend: "log.design". and so on for basically any section id that is used in the QuickBook [link] tag. In the resulting HTML documentation all such links point to the root directory where the HTML docs are located. Looking at the bin.v2/libs/log/doc/log_doc.xml file, for example, for the log.detailed.sink_frontends.sync is, it looks like <link> tags use the id that is specified in QuickBook: <link linkend="log.detailed.sink_frontends.sync"> but the actual section has a colon in front of the id: <section id=":log.detailed.sink_frontends.sync"> Is this a known issue and is there a workaround? I'm using DocBook XML from the Kubuntu package, which has version 4.5-9, and a freshly built QuickBook from develop. I used to build docs locally fine before, and did not change the configuration since, but I may have upgraded Kubuntu since I last built the docs. Thanks.

2 5

[release] 1.76.0 closes for major changes TOMORROW
by Marshall Clow 04 Mar '21

04 Mar '21

When: Wednesday, Mar 3, 2021 Description: Release closed for major code changes. Still open for serious problem fixes and docs changes without release manager review. Full calendar at: https://www.boost.org/development/ <https://www.boost.org/development/> — Marshall

3 3

Re: [boost] [Describe] Boost.Describe vs Boost.Fusion
by Nikita Kniazev 02 Mar '21

02 Mar '21

> Or have Spirit perform a check: if `describe::members` is found use it, otherwise fall back to Boost.Fusion. Spirit uses Fusion iterator_range internally, it will require to find/write a replacement that will work with both libraries.

1 0

AVL Databases and Boost Serialization in C++
by Benedict NNcNannara 02 Mar '21

02 Mar '21

AVL Databases were invented in C# and Java in 2016. More recently (2022) AVL Databases were invented in C++. They were a port of the C# code back to C++. In fact, the port was of a larger system - The Generic Language. Boost Serialization Library was used to serialize a general datatype t in set<t>. This applies to the C++ Variant of AVL Databases, The Generic Language Compiler uses AVL Databases to store its code. Execution occurs directly out of the code database, thus no loader is required. In fact the multithreaded, monolithic runtime is very fast compared to the C# version which is now obsolete. uuindouus.zip <https://drive.google.com/file/d/1NhEEmfZMf5yGbnsTAHH1N-XAjPCbczAy/view?usp=…>

5 5

1.76 schedule?
by John Maddock 01 Mar '21

01 Mar '21

Just noticed that the calendar has master closed for breaking changes from yesterday... I was hoping to do a Math & Multiprecision release, but they drop C++03 and have some massive restructuring/changes as a result. On the plus side they're better tested than they probably ever have been. So... too late for 1.76 or not? Thanks, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

4 4