- Boost - lists.preview.boost.org

[geometry] Boost 1.73 beta docs include broken links to Geometry Extensions
by Mateusz Loskot 19 Apr '20

19 Apr '20

Hi, I asked about it here a while ago, but without responses [1] https://lists.boost.org/Archives/boost/2020/03/248531.php We have been observing this problem since 1.70 and we have pretty much run out of ideas what is wrong with Boost.Geometry setup [2] https://github.com/boostorg/geometry/issues/585#issuecomment-605106308 The issue is still observed in the 1.73 beta docs [3] https://github.com/boostorg/geometry/issues/585#issuecomment-614263295 Could anyone help us understand [2] what is the problem with our docs? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

Wrong boost.173-beta1 tag for boost.test
by Raffi Enficiaud 18 Apr '20

18 Apr '20

Hi, I just noticed that the tag "boost-1.73-beta1" points to e8b173655c207ec2286227fe17f2e1f68ce44f17 in boost.test, while master points to 9a8cdba280a9c5dc60c4781a26e055ebfe2446ea, and the content of the boost_1_73_0_b1_rc1.tar.bz2 archive is the same as master. I am expecting that the tag "boost-1.73-beta1" points to the content of the archive boost_1_73_0_b1_rc1 . Raffi

2 1

Git documentation is full of twisty passages
by Jonathan Wakely 17 Apr '20

17 Apr '20

I've once again got lost trying to find how to check out Boost from Git. I started at boost.org and (after some missteps) went to https://www.boost.org/users/download/#repository which tells me "Details of the git repositories are on the Boost wiki." https://svn.boost.org/trac/boost/wiki/ModularBoost That takes me to a page with about 20 links. Eventually I decided that the 13th one is the one I want: Getting Started with Modular Boost https://svn.boost.org/trac10/wiki/TryModBoost That takes me to a page that says: "This page is superseded by https://github.com/boostorg/boost/wiki/Getting-Started Please help migrate the rest of the old wiki !" But when I go to that page it says: "The Boost Wiki is at: https://github.com/boostorg/wiki/wiki" So I go there instead, which has nothing about Git. The "Getting Started" page has a link to "Getting Started with Modular Boost Library Development using Git" right at the very bottom, and the "Getting Started - Using Git" link in the sidebar takes me to a different page with very generic Git info (not specific to Boost), and again, near the bottom, is the "Getting Started with Modular Boost Library Development using Git" link. So I click that and ... I'm back in Trac, at https://svn.boost.org/trac10/wiki/StartModWorkflow I don't care bout Boost's use of Git Flow. I don't care about your branching policy, I want to check out the repo! It turns out that on the front page of https://github.com/boostorg/wiki/wiki I should have clicked the "Cheat Sheet" link in the sidebar: https://github.com/boostorg/wiki/wiki/Getting-Started%3A-Cheat-Sheet Could you please make that easier to find from boost.org? It seems to me that https://www.boost.org/users/download/#repository should just link straight to that cheat sheet, or to another page with the correct git submodule commands for checking out the repo.

2 3

Fwd: teeks / boost.test: some test files not found
by Raffi Enficiaud 16 Apr '20

16 Apr '20

I am cross-posting this on the dev mailing list as I would like to know how to fix this before the 1.73 deadline. Thanks and sorry for cross-posting, Raffi -------- Forwarded Message from the test gmane group Hi, On some teeks workers, I have this strange issue: teeks99-09-p-64: https://www.boost.org/development/tests/develop/developer/output/teeks99-09… The error says: .../libs/test/test/framework-ts/log-formatter-test.cpp(117): error: in "test_logs": check output.match_pattern(true) has failed: Pattern file can't be opened! which means some files used for testing, such as test/test/baseline-outputs/log-formatter-test.pattern , are not found. Those files are advertised in the Jamfile, https://github.com/boostorg/test/blob/develop/test/Jamfile.v2#L145 I guess it would be a hard error on b2 if the files were not found. What should I do such that those workers find the test files? I recently added one file to the previous 2 existing files. Thanks, Raffi

1 0

[Graph] Min Cut with float weights
by Phil Endecott 16 Apr '20

16 Apr '20

Dear Experts, I am attempting to use stoer_wagner_min_cut for the first time. Using float as the edge weight type seems to be problematic for non-trivial graphs. I think this is possibly because it adds an edge weight to the cut weight and then later subtracts the same value, but doesn't get back to exactly the previous value due to loss of precision. The errors accumulate and eventually the reported cut weight is nonsense. I am now trying with integer weights but I worry that this could suffer overflows. If my edge weights are in the range 0...W, for a graph with E edges the largest cut weight would be < W*E. But does the algorithm ever use larger values internally? Also, I'd be interested if anyone has tried to break a graph into subgraphs by recursively breaking at the min_cut until the min_cut weight is below some threshold. I have a graph with of the order of 10^4 vertices and 10^6 edges and this would be tractable if the min_cuts broke the graph into roughly equal pieces; instead, they tend to remove a small number of vertices each time, leaving almost as much work for the next recursion. So I think I want to find a cut whose weight is below a threshold and that is in some sense locally minimal and that leaves two largish subgraphs. Any ideas? Cheers, Phil.

1 0

Reminder: 1.73.0 master branch closes one week from today
by Marshall Clow 15 Apr '20

15 Apr '20

22-Apr Boost 1.73.0 closed for release ASAP Boost 1.73.0 release -- Marshall

1 0

Re: [boost] MySQL ASIO library
by Andrey Semashev 14 Apr '20

14 Apr '20

[Sending this reply to list as opposed to personal email] On Wed, Mar 4, 2020 at 3:39 PM Richard Hodges <hodges.r(a)gmail.com> wrote: > On Wed, 4 Mar 2020 at 13:25, Andrey Semashev <andrey.semashev(a)gmail.com> wrote: >> >> On Wed, Mar 4, 2020 at 1:50 PM Richard Hodges via Boost >> <boost(a)lists.boost.org> wrote: >> > >> > > Why just MySQL? >> > >> > Getting something useful released is more important than getting something >> > perfect released. >> > >> > If Ruben has a ready-to-go solution for MySQL, why not make it available to >> > users? >> >> Making it available to users is not the same as making it part of >> Boost. Boost is known for general purpose libraries, as well as more >> domain-focused solutions, but it is not a place for wrappers around >> specific other libraries. Let alone, when the said libraries already >> have C/C++ API. > > Boost also has mpi, regex, asio::ssl and python. What are these if not wrappers around common c libraries? I'm not sure about Boost.MPI, but I thought it was not a wrapper of a single library, but of a standard API that can be implemented by different libraries. Boost.Regex is not a wrapper at all; it implements regular expressions from scratch. asio::ssl is not a library but a plugin for Boost.ASIO that provides one small piece of functionality compared to the rest of the library. Boost.Python is probably closest to an exception, although it is a binding to another language (not a library), which arguably only has one C API and implementation. Yes, there is CPython, but I don't believe it offers a C API. >> > It can always be complemented or extended with Oracle, SQLite, ODBC etc etc >> > later. >> >> If the proposed library offers a stable and flexible API that can be >> backed by multiple implementations then by all means - that would be a >> very interesting proposal indeed. But the author has to demonstrate >> that the proposed user API can in fact be supported by more than one >> backend, so at least two backends need to be presented, and preferably >> with guidelines and infrastructure for adding more. > > Mpi, regex and python would dispute this arbitrary restriction. I don't think so, as per above. > Boost suffers from a lack of contribution. Is there any value in making contribution difficult? I don't think the amount of contributions by itself is the goal. There has to be value associated with the contribution. I just don't think a C++ wrapper of a specific library has enough value.

11 28

Code coverage tests
by Edward Diener 14 Apr '20

14 Apr '20

A number of libraries have code coverage/project tests in Github. I am not against such tests but I am against the idea that "failing" such a test, whatever that means, should prevent a PR from being merged into a Boost library. To me it is nonsense that a perfectly logical change to software should lead to some code coverage "failure", and that therefore the change should be deemed incorrect. I admit I do not know what the criteria are for code coverage but I do not see code coverage determining whether any change to a library is incorrect or not.

11 19

[release] Boost 1.72.0 Beta 1
by Marshall Clow 12 Apr '20

12 Apr '20

Boost release 1.73.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.73.0.beta.1/source/> The SHA256 checksums are as follows: 44f323b42c4375ab3751b67ac5ce53ba5267af20cf375be75675d8952d3cca4e ./boost_1_73_0_b1.7z 5270fa89243a3508331bd3773800de6d2f98d1f160b95e362fa8269d9cd58773 ./boost_1_73_0_b1.tar.bz2 82ffcd4a2e558a31f1ddd6a54ef6c00dae28b95c2ddee575c285544085dcb004 ./boost_1_73_0_b1.tar.gz 910b7560ee239472cc69e6a0c680dc4d9d7ea234faad807738ec98e4811c63d4 ./boost_1_73_0_b1.zip For details of what's in the release, see <https://www.boost.org/users/history/version_1_73_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

1 0

[release] Boost 1.73.0 Beta 1 Release Candidate 1
by Marshall Clow 10 Apr '20

10 Apr '20

The release candidates for the first 1.73.0 beta release are now available at: https://dl.bintray.com/boostorg/beta/1.73.0.beta.1/source/ The release notes are not yet available. The SHA256 checksums are as follows: 44f323b42c4375ab3751b67ac5ce53ba5267af20cf375be75675d8952d3cca4e ./boost_1_73_0_b1_rc1.7z 5270fa89243a3508331bd3773800de6d2f98d1f160b95e362fa8269d9cd58773 ./boost_1_73_0_b1_rc1.tar.bz2 82ffcd4a2e558a31f1ddd6a54ef6c00dae28b95c2ddee575c285544085dcb004 ./boost_1_73_0_b1_rc1.tar.gz 910b7560ee239472cc69e6a0c680dc4d9d7ea234faad807738ec98e4811c63d4 ./boost_1_73_0_b1_rc1.zip 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 Boost Release Managers

4 6

Re: [boost] [Boost-users] 404 GMane link in Boost.FileSystem doc
by Glen Fernandes 09 Apr '20

09 Apr '20

On Thu, Apr 9, 2020 at 6:15 AM Dominique Devienne wrote: > > Over at > https://www.boost.org/doc/libs/1_72_0/libs/filesystem/doc/reference.html#pa… > (and older version of the doc too) there's a link to > http://permalink.gmane.org/gmane.comp.lib.boost.devel/199744 > which is no longer so permanent :). According to https://en.wikipedia.org/wiki/Gmane > the website is no longer available. I guess any GMane link in docs should be updated > to another ML archive. Yes, the link should be updated to: https://lists.boost.org/Archives/boost/2010/02/162028.php Created https://github.com/boostorg/filesystem/commit/aaf54ada48b8da2bfc22b87d2890a… Glen

1 0

[release] 1.73.0 closed for Beta
by Marshall Clow 09 Apr '20

09 Apr '20

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_73_0.q… > Thanks, -- The Boost Release Team

1 0

1.73.0 Beta Deadline this Wednesday 4/8
by Marshall Clow 09 Apr '20

09 Apr '20

The deadline for major changes has passed. Upcoming dates: 8-Apr Boost 1.73.0 closed for beta ASAP Boost 1.73.0 beta 22-Apr Boost 1.73.0 closed for release ASAP Boost 1.73.0 release "ASAP", in this list, means "As soon as possible after the preceding milestone" -- Marshall

6 16

boost [math] excessive warnings via [lexical_cast] from [date_time] (and others) for clang 3.4?
by Jeff Garland 08 Apr '20

08 Apr '20

In the regression tables the following warnings are coming out of math config. I'm trying to understand what this means given that 1) the tests compile and execute fine, 2) the deadline is up, and 3) several of the cases are compiled in c++11 mode (is it pre conformance bc it's clang3.4?). I've seen this warning in other places that include lexical_cast as well. So sure I could go and define the macro to quiet this, but seems like that should be done closest to the source. In other words maybe math should only tell us that in headers that have a real issue? Or will this soon be a real issue? ../boost/math/tools/config.hpp:42:9: warning: CAUTION: One or more C++11 features were found to be unavailable [-W#pragma-messages] ../boost/math/tools/config.hpp:43:9: warning: CAUTION: Compiling Boost.Math in pre-C++11 conformance modes is now deprecated and will be removed from March 2021. [-W#pragma-messages] ../boost/math/tools/config.hpp:44:9: warning: CAUTION: Define BOOST_MATH_DISABLE_DEPRECATED_03_WARNING to suppress this message. [-W#pragma-messages] Full examples https://www.boost.org/development/tests/develop/developer/date_time.html https://www.boost.org/development/tests/develop/output/teeks99-dkr-dc3-4-98…

5 23

Gsod20 interest
by Damian Vicino 08 Apr '20

08 Apr '20

Hi, I'm wondering if there is interest in submitting boost as a potential org for Google season of docs (https://developers.google.com/season-of-docs) Also, if someone would like to be mentor on it, that would be great to know too. Best regards, Damian

2 1

Boost local unix domain example for IPC
by Jupiter 08 Apr '20

08 Apr '20

Hi, I am doing boost local unix domain for IPC, I midified the code based on sample code from boost_asio/example/local/stream_server.cpp, I am a little bit puzzled for errors calling different async_read, if I call original code using shared_from_this() it works fine: boost::asio::async_read(this->mSocket, boost::asio::buffer(this->mData), boost::bind(&session::HandleRead, shared_from_this(), boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); But if I tried to run a following lambda function which works in in my other boost asio TCP socket, it got an error "Operation canceled", what I could be missing here? Or do I have fundamontal problems in the lambda function I used for other TCP socket programs? boost::asio::async_read(this->mSocket, boost::asio::buffer(this->mData, sizeof(this->mData)), [=](const boost::system::error_code &status, const uint32_t size) {this->HandleRead(status, size);}); Thank you. Kind regards, - jh

2 2

[xpressive] Where are the names in the c_ctype.h file coming from
by Edward Diener 07 Apr '20

07 Apr '20

In the xpressive header file c_ctype.h there are names such as _ALPHA, _UPPER, _LOWER, _DIGIT etc. Where are these names declared or defined ? I searched through all the Boost libraries and did not find any of these names declared or defined anywhere. Are they supposed to be part of some C++ standard header file ?

1 0

Asio, gcc and -fconcepts
by Richard Hodges 07 Apr '20

07 Apr '20

Dear all, With the upcoming Boost 1.73 release imminent, I felt it was worthwhile pointing out that latest gcc has a problem with Asio if the `-fconcepts` command line flag is set. There is an issue in the Boost.Asio repo here relating to the manifestation of the bug in MSVC: https://github.com/boostorg/asio/issues/312 and an issue here in the Boost.Beast repo: https://github.com/boostorg/beast/issues/1884 It seems that the file boost/asio/detail/config.hpp was written when concepts support was not widespread and still in the concepts.ts stage. The syntax and capabilities of concepts were subtly changed during standardisation, with gcc and MSVC only supporting the C++20 dialect. Thus, compiling an Asio-based program with concepts enabled in either of gcc or MSVC fails unconditionally. I'm wondering if anyone has Chris' ear and might ask him to indulge us with a fix prior to the 1.73 release. I fear that by the time Boost 1.73 is in mainstream use, C++20 will be upon us we'll see an increase in issues and a loss of reputation as a result. Thanks for your time, Sincerely, -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

3 4

[Performance of circular_buffer vs Queue][Multithreading may be broken]
by Jan Hafer 04 Apr '20

04 Apr '20

Dear Boost developer, I found the circular buffer to be slower than std::queue for multithreading except in the case of a single thread (where it is notably faster). I am using resize() to have the expected size filled as in vector. Is this behavior expected or documented anywhere? What kind of speedup is to be expected against the std::queue implementation? If there is none, then what is the purpose of circular buffer? I do also have broken code on a multithreaded application that worked fine before. I do pass the circular buffer as reference via functions from file scope, which in combination with the threads (initially starting elsewhere) somehow broke the code. Do you do regular benchmarks against other implementations? I dont see linked graphs on your homepage. Regards, Jan

7 10

[1.73][thread] Merge to master and apply PRs
by Andrey Semashev 04 Apr '20

04 Apr '20

Hi, There are a number of fixes in Boost.Thread develop that I would like to see in 1.73, but they are not merged to master. The last commit to develop was in Dec 2019, so plenty of time has passed for testing. I'd like to ask someone to merge develop to master. https://github.com/boostorg/thread/issues/311 Also, there are two PRs hanging for quite some time that I would also like to see in 1.73: https://github.com/boostorg/thread/pull/309 https://github.com/boostorg/thread/pull/310 I'd like to ask someone with merge permissions to have a look and merge them (first to develop, and then to master, after testing). I tried pinging Vicente, but he is not responding. Most of the changes in develop and the PRs are aimed to resolve various warnings generated by Boost.Thread, including using deprecated features of Boost.Bind, Boost.WinAPI and C++. Thanks.

1 0

Re: [boost] Linking libboost_python.so to libpython
by Peter Dimov 03 Apr '20

03 Apr '20

> That's why you weren't getting the error before 1.72, but not the reason > why libboost_serialization ends up with the different property sets. FWIW, my Travis build/install of --with-mpi works: https://travis-ci.org/github/boostorg/boost_install/jobs/669821455 and I can't find the place that's setting <dll-path>/usr/lib <dll-path>/usr/lib/python3.8/config.

2 1

Linking libboost_python.so to libpython
by Jonathan Wakely 03 Apr '20

03 Apr '20

tools/build/src/tools/python.jam says: # On *nix, we do not want to link either Boost.Python or Python extensions # to libpython, because the Python interpreter itself provides all those # symbols. If we linked to libpython, we would get duplicate symbols. So # declare two targets -- one for building extensions and another for # embedding. Why would that give duplicate symbols? Wouldn't ELF symbol interposition mean that only one is used? Why would it be a problem to link to libpython? In Fedora's Boost RPM packages we *do* link libboost_python.so to the system libpython (and we don't get any problems). But to do this, we have these two local patches: https://src.fedoraproject.org/rpms/boost/blob/master/f/boost-1.57.0-python-… and then to make it link to libpython3.7m.so (rather than libpython3.7.so) we have this patch to pass the "m" into the Boost build: https://src.fedoraproject.org/rpms/boost/blob/master/f/boost-1.66.0-python-… I'd prefer not to need these local hacks. Would the upstream Boost.Python consider making changes so that libboost_python.so can be (optionally) linked to libpython? Is there a cleaner way to do this than those patches?

5 12

Regarding GSoC 2020 Proposal for uBLAS Dataframes
by Tom Kwok 02 Apr '20

02 Apr '20

Hi everyone, I have submitted a final PDF version of my GSoC 2020 Proposal for uBLAS Dataframes, just before the deadline yesterday. I would be looking forward to receiving feedback from potential mentors. Today I read my final proposal again and I noticed a bunch of typos, such as incorrectly stating “heterogenous” columns for a data frame (which should be “homogeneous” columns since they are single-typed), and a few others. I am very sorry for the typos due to rushed drafting and submission. I am aware that it would be unfair to other participants to make corrections after the deadline, and please take the final PDF version submitted for review. Here I am only trying to let reviewers know, when they give comments, that I am already aware of some of the minor typos, which are fixed in a patched version of my proposal accessible via the submitted link to “draft” that points to a Google Drive document that I can update at any time (with document creation date in the heading generated by my Latex template). Best regards, Tom

2 1

[gil] Review of move assignment operator for image class
by Mateusz Loskot 02 Apr '20

02 Apr '20

Hi, We're adding move semantics to some of GIL classes [1] and we'd like to receive feedback on the move-assignment operator for the image class [2] (copied below) that we've worked out so far if there are any major blunders to correct or gaps to fill for C++11 compliant implementation: image& operator=(image&& img) { if (this == std::addressof(img)) return *this; auto const exchange_memory = [](image& lhs, image& rhs) { lhs._memory = boost::exchange(rhs._memory, nullptr); lhs._align_in_bytes = boost::exchange(rhs._align_in_bytes, 0); lhs._allocated_bytes = boost::exchange(rhs._allocated_bytes, 0); lhs._view = boost::exchange(rhs._view, image::view_t{}); }; constexpr bool pocma = std::allocator_traits<Alloc>::propagate_on_container_move_assignment::value; if (pocma) { // non-sticky allocator, can adopt the memory, fast destruct_pixels(this->_view); this->deallocate(); this->_alloc = img._alloc; exchange_memory(*this, img); } else if (_alloc == img._alloc) { // allocator stuck to the rhs, but it's equivalent of ours, we can still adopt the memory destruct_pixels(_view); this->deallocate(); exchange_memory(*this, img); } else { // cannot propagate the allocator and cannot adopt the memory if (img._memory) { allocate_and_copy(img.dimensions(), img._view); destruct_pixels(img._view); img.deallocate(); img._view = image::view_t{}; } else { destruct_pixels(this->_view); this->deallocate(); this->_view = view_t{}; } } return *this; } One thing that is still missing is the noexcept with expression evaluated based on something like this template <class _Alloc> using is_noexcept = std::conditional_t < std::allocator_traits<_Alloc>::is_always_equal::value, _Equal_allocators, typename std::allocator_traits<_Alloc>::propagate_on_container_move_assignment::type >; but we there is no is_always_equal in C++11, so there are gaps to fill. Any comments are appreciated. [1] https://github.com/boostorg/gil/pull/457/ [2] https://github.com/boostorg/gil/blob/7d8df1c105e81070e30ef68ea7abb8e39111d6… Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

Request to review my GSoc Proposal[Boost multiprecision
by suyashtava 01 Apr '20

01 Apr '20

Dear Sir/Ma'am, It would be great if you could review my GSOC proposal for [Boost multiprecision]: New Big-Double Backend Types Doc link: https://docs.google.com/document/d/1xznSxg1XcAiQMnVXSMG_NwxuUeGmkI5iXhabSXe… I deeply regret and apologize for the late submission, but I request you to review it once as it will surely help me to update it in required ways. With regards Suyash Srivastava IIT(ISM) Dhanbad -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

5 6

[GSoC2020][Boost.Real] Greeting
by Firmin Martin 01 Apr '20

01 Apr '20

Hi, Boost community! This mail is not intended to serve as a proposal review (it's too late obviously). Instead, I would want to greet my potential mentors and possible collaborators. Anyway, whether or not my proposal is retained, I will probably still contribute after GSoC 2020 since I've got familiar enough to the codebase by dint of reading blog posts, references and code sources. I made a small PR involving BBP formula to compute the n-th binary digit of pi and already submitted my final proposal to GSoC. Best regards, Firmin

2 1

Download links all broken?
by John Maddock 31 Mar '20

31 Mar '20

All the download links from www.boost.org appear to be currently broken - which is to say no one can download Boost right now. Ideas or fixes anyone? Thanks, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

10 21

[test][program_options] Avoid deprecated bind placeholders in global namespace
by Mateusz Loskot 31 Mar '20

31 Mar '20

Hi, I have a shy request to maintainers of boostorg/test and boostorg/program_options Would it be possible to merge these trivial patch to both: https://github.com/boostorg/test/pull/259 https://github.com/boostorg/program_options/pull/92 Thanks in advance. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Proposal Review
by Kishan shukla 31 Mar '20

31 Mar '20

Hello everyone, I have prepared the draft proposal for the boost.Real project. It involves adding new mathematical functions and operators into the library. I have also planned on optimizing a few algorithms and addressing previously unresolved issues. The proposal is the result of my discussion with my mentor Damian Vicino. Sorry for being late. Please review the proposal and provide your valuable feedback. Proposal link: https://docs.google.com/document/d/1oXAaaiqgtC2bTCfADPwXUY4ItYw-C8EMOLr2Bhu… Regards, Kishan Shukla

2 2

GSoC 2020
by Sachin Saw 31 Mar '20

31 Mar '20

Dear Developers, I am Sachin, a third year undergraduate student at Indian Institute of Technology Kharagpur, I have been using C++ for around three years and have a good experience in it. I like to contribute to boost on Boost.Geometry during GSoC’20. I went through https://www.iis.sinica.edu.tw/page/jise/2012/201205_10.pdf and found a great explanation of algorithm during GSoC period I would like to work on above algorithm (in the link) and concave hull using k-nearest neighbours approach so that one would act as a test for other. If would love to have suggestion from you Thanks,

2 3

[gsoc20] Proposal review for Boost.Real
by Vikram Chundawat 31 Mar '20

31 Mar '20

Hello everyone, I have prepared my draft proposal for Boost.Real project on improving the base, adding new number types and adding a method to calculate powers. Here is the link to the proposal https://docs.google.com/document/d/10Hy87Ok7UTzqPvzD35BkrlL-Sx4G8HfSCzchwYa… I have been in touch with this project's potential mentor Damian Vicino and this proposal is the result of my discussion with him. Please kindly provide your valuable feedback on the proposal. Thank you Regards Vikram Singh Chundawat

2 2

[gsoc20]Proposal for general robust predicates for Boost.Geometry
by Tinko Bartels 30 Mar '20

30 Mar '20

Hello Boost-Community, I have prepared a draft proposal for general robust predicates for Boost.Geometry. The ideas are described in more detail in the proposal, but I will briefly describe them here: A number of geometric algorithms, such as the triangulation of a point set, employ geometric predicates (implemented as strategies in Boost.Geometry). One example for such a predicate is the 2d orientation test, which, given three points p1, p2, p3, determines whether p3 lies on the left or right side of the line segment that goes through p1 and p2. Using floating-point arithmetics to answer that question can lead to incorrect and ultimately inconsistent results that may cause the algorithm that employs the predicate to produce nonsensical results or crash entirely for certain inputs. Using algorithms for exact floating-point arithmetics combined with some considerations regarding forward error analysis, a complicated method can be implemented that evaluates such predicates robustly and only adaptively increases the precision if necessary to avoid expensive high precision computations whenever possible. I propose a general, automated approach that generates such robust, adaptive predicates from arbitrary arithmetic expressions. Currently, Boost.Geometry has robust adaptive predicates for the 2d orientation and the 2d incircle test. This work would enable us to easily extend this to 3d orientation, 3d insphere, and generally all predicates that can be evaluated by determining the sign of a polynomial. I want to present my proposal for review publicly now: https://docs.google.com/document/d/19zH9QuSSNWAHm1DP5poxbRxcMXlzRVWfL5Wslbe… Kind regards Tinko Bartels -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

3 3

[cmake][array][vs] Trying develop and test a single library
by Mateusz Loskot 30 Mar '20

30 Mar '20

Hi, I'm learning about the boostorg/cmake infrastructure offered by Peter. I picked Boost.Array as a library with simple build setup. I replaced the existing (hand-rolled?) CMakeLists.txt files with the generated ones: b2 tools\boostdep\build dist\bin\boostdep.exe --cmake array Then, learning form boostorg/cmake itself how to use it https://github.com/boostorg/cmake/blob/develop/.travis.yml#L228 cd BOOST_ROOT mkdir __build__ && cd __build__ cmake -DBOOST_ENABLE_CMAKE=1 -DBoost_VERBOSE=ON -DBOOST_INCLUDE_LIBRARIES=array .. cmake --build . ctest --output-on-failure -R boost_array Visual Studio solution is nicely generated, all expected .vcxproj files too, but, AFAICT, neither the last two commands nor these do anything: cmake --build . --config Release cmake --build . --config Debug I loaded the Boost.sln in VS 2019 and Build > Build Solution worked. I also noticed this 'unusual' project-as-target called check. I'm back in the CLI mode and run: cmake --build . --target check this time all the tests build and run. Interestingly, if I feed the ctest with the build configuration, then it also builds the tests, and runs them too, of course: ctest --output-on-failure -R boost_array -C Release ctest --output-on-failure -R boost_array -C Debug Is this `cmake --build .` doing nothing specific Boost.CMake? Is that `check` target supposed to be used explicitly? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

4 8

FW: Request to review my GSoC proposal[Boost multiprecision]
by Kindly review GSOC Proposal [Boost multiprecision]: New Big-Double Backend Types 30 Mar '20

30 Mar '20

Sent from [1]Mail for Windows 10 From: [2]Kindly review GSOC Proposal [Boost multiprecision]: New Big-Double Backend Types Sent: Monday, March 30, 2020 2:14 PM To: [3]boost(a)lists.boost.org Subject: Request to review my GSoC proposal[Boost multiprecision] Dear Sir/Ma'am, It would be great if you coul review my GSOC proposal for [Boost multiprecision]: New Big-Double Backend Types Doc link: [4]https://docs.google.com/document/d/1xznSxg1XcAiQMnVXSMG_NwxuUe GmkI5iXhabSXe_WuQ/edit?usp=sharing I deeply regret and apologize for the late submission, but I request you to review it once as it will surely help me to update it in required ways. With regards Suyash Srivastava IIT(ISM) Dhanbad Sent from [5]Mail for Windows 10 References 1. https://go.microsoft.com/fwlink/?LinkId=550986 2. mailto:suyash.17je003210@cse.iitism.ac.in 3. mailto:boost@lists.boost.org 4. https://docs.google.com/document/d/1xznSxg1XcAiQMnVXSMG_NwxuUeGmkI5iXhabSXe… 5. https://go.microsoft.com/fwlink/?LinkId=550986

1 0

feedback on litpton-tarjan separator
by Jeff Linahan 30 Mar '20

30 Mar '20

Hello BGL users, after 5 years I'm almost ready to start writing documentation for my lipton-tarjan planar separator algorithm and finally submit my first implementation for formal peer review for inclusion in BGL. But one last question I have is feedback on how people would like the public interface for how a function like this will work (especially the template part which I'm not as good at). The internals will be easier to change as I continue to develop the implementation. This is essentially what I have now: struct Partition { std::set<vertex_t> a, b, c; }; Partition lipton_tarjan_separator(boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_index_t, uint>, boost::property<boost::edge_index_t, uint>> const&); I'd like to make it more generic eventually, but is that good enough for inclusion in BGL as is? Full code here: https://github.com/jeffythedragonslayer/lipton-tarjan Thanks, Jeff

1 1

Google Code Summer Challenge
by Calvin Green 30 Mar '20

30 Mar '20

Dear Boost C++, Hello, my name is Calvin Green Jr. I am a sophomore Computer Science major from Chicago, IL. I was emailing you to see if you can send me your guy's Google Challenge mentor's emails or assign me to one for the Summer challenge. Sincerely, Calvin Green

2 1

[GSoC 2020] Extraordinary circumstances and early birds
by madhur4127 29 Mar '20

29 Mar '20

Hi Boost Community, I am Madhur, an active contributor to Boost.Multiprecision. I am from India and am observing that summer internships (for students in the penultimate year) are being canceled because of COVID-19. This is a huge loss to brilliant and enthusiastic students as they will not be able to gain experience. This could be an opportunity for Boost to mentor these students who don't have prior experience with open source or with a rich C++ background. If a student is ready to devote himself/herself then I guess there's enough time to learn (till Jun 1) about C++/Project to get things rolling. > FYI, you are late. Mateusz posted in other thread about the student being late (as of today) but the GSoC application deadline is due March 31, which I would wholeheartedly agree in case of normal circumstances. The point I'm trying to make here is that in these extraordinary circumstances: - should Boost neglect the "early bird" and treat all applicants equally? - should Boost compensate for the lack of work samples with the history of the student (like academic records, academic projects, research papers)? - should Boost consider other factors too while selecting the student this year like the education level (seniority level: 4th/5th year of study or PhD)? For example, if a student had taken a course in numerical algorithms/computational algorithms then that applicant's insights could be beneficial to Boost.Multiprecision than other applicants. If a student performs well in the competency test then it indicates that the student would do the job and I think the selection criteria should be tweaked so as to consider that students who lost internships and otherwise who could be a great value to the library (even for a short time - GSoC) don't get neglected. Well, these are my views as a student. Eagerly waiting for your thoughts! Thank you for having time to read this unusually long message :) -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

7 7

[GSoC20] Seeking mentor
by Martin Carrasco Castaneda 29 Mar '20

29 Mar '20

Hello, I am seeking a mentor for the GSoC program for this year. I have some experience with DSP and just submitted a very basic PR with a filter implementation. I find this topic very interesting and have some general ideas for available mentors. I'd like to work in implementing features for deblurring such as the Weigner filter or the Least Square filtering. I am also interested in working in feature extraction filters such as the Hough transform or related subjects. I am pretty much open to any subject relating to GIL. Thanks for the responses in advance, Regard, Martin -- La información contenida en este e-mail y sus anexos es confidencial, privilegiada y está dirigida exclusivamente a su destinatario, en consecuencia, solo puede ser utilizada por aquel. Si usted no es el destinatario original, no deberá examinar, usar, copiar o distribuir este mensaje o la información que contiene. Si lo recibe por error, por favor reenvíelo a la persona que se lo envió y elimínelo. Cualquier retención o uso total o parcial no autorizada de este mensaje está estrictamente prohibida y sancionada por ley.

2 1

[gil][GSoC20] Proposal review
by Laxmikant Suryavanshi 29 Mar '20

29 Mar '20

Hi Boost Community, I have prepared a proposal for GSoC-2020 for Boost.GIL project `Implementation of Image Processing Algorithms`. I would like to review it and hear comments from you. https://docs.google.com/document/d/1qSYC_94ia28xutmW_qrC3pcSXJ8opfdxW514xRF…

2 2

Regarding PCT (boost astronomy , coordinate transformation/conversion)
by GOPAL RAMESH DAHALE 28 Mar '20

28 Mar '20

I have written a class to transform cartesian_representation vector with the help of the affine matrix(3x3). My problem is that I am not able to work with boost::unit:: quantity. I work with the quantity values but later on not able to assign it to the resulting cartesian_represtentaion(res). Any help is appreciated. Thank You.

2 1

[boost.multiprecision] Request to review GsoC proposal.
by Abhay Yadav 28 Mar '20

28 Mar '20

Hello, I have prepared the GsoC proposal. Please provide your valuable feedback. Proposal link : https://docs.google.com/document/d/1j9avtkQALwnesyKAq40wFtPaA1Adp2RUf3FUGCP… Thank you Regards, Abhay Singh Yadav

1 0

Fwd: new toolset in b2
by Grzegorz Konopko 28 Mar '20

28 Mar '20

Dear I am thinking about make automatic test for boost, but with not supporting toolset yet. Is there any tutorial or template for b2: how to add new toolset support? I was looking documentation already, in my opinion no simply way due lack of kind of "easy tutorial". Best regards Grzegorz Konopko

1 0

Hiring mentors for Google Summer of Code 2020
by David Bellot 28 Mar '20

28 Mar '20

Hi Boost community, we are recruiting the mentors for the Google Summer of Code 2020. If you wish to be a mentor, please contact me directly and I'll send you an invite. We need at least 10 mentors this year. Obviously, a mentor comes with ideas of projects and proposals for this Summer. Best regards, David

8 10

Looking for Boost.uBlas data frames project GSoC mentors
by Tom Kwok 28 Mar '20

28 Mar '20

Hi everyone, May I know if there are any potential mentors for my Boost.uBlas data frames project proposal besides Mr. David Bellot? He has not been responding to messages lately. Not sure if it is because of the recent Covid-19 situation. Best regards, Tom

6 12

[geometry] Global Boost documentation for master not refreshed?
by Mateusz Loskot 27 Mar '20

27 Mar '20

Hi, A long while ago there was a problem in Boost.Geometry [1] that caused addition of unwanted sections to the global docs: https://www.boost.org/doc/libs/1_70_0/#lib-geometry-extensions https://www.boost.org/doc/libs/1_70_0/#lib-geometry-index and the problem [1] has been fixed a while ago in the Geometry, in both branches develop and master. [1] https://github.com/boostorg/geometry/issues/585 The global docs for the develop branch look fixed, no unwanted sections, just the one we want: https://www.boost.org/doc/libs/develop#lib-geometry The global docs for the master branch still lists one of the two unwanted sections https://www.boost.org/doc/libs/master#lib-geometry-extensions Why is that? Are we still waiting for the rebuild or something had not cleaned up correctly before the last rebuild? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Boost Astronomy gsoc
by GOPAL RAMESH DAHALE 27 Mar '20

27 Mar '20

I want to contribute to boost astronomy in gosc and I have read that I have to find a mentor who is an experienced boost developer and then write the proposal. What should I do? I am not able to understand the procedure for contributing to boost. Please help. I appreciate that. Thank you.

2 1

uBlas and Google Summer of Code 2020
by David Bellot 27 Mar '20

27 Mar '20

Hi Boost community, I've added new projects for the Google Summer of Code 2020 for the Boost uBlas library (matrix computations, tensors and linear algebra). If you're a student and wish to candidate, please contact me as soon as possible. The list of projects is here: https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code%3A-2020 Cheers, David

4 5

[GSoC 2020] Proposal Review
by deb 27 Mar '20

27 Mar '20

Here is my proposal for GSoC 2020. It takes into account the new timeline announced today. I do not ask for a full review (which can be done after the final submission) just a glance from the potential mentors to provide feedback on any section I might have missed or needs to be modified. Link to docs - https://docs.google.com/document/d/1qZZSuTF2xQoZVnkVeahDDIMlIJ5iiSUn0BMJxo7… Thanks in advance. Debabrata Mandal -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

1.73.0 Release process has started!
by Marshall Clow 26 Mar '20

26 Mar '20

The deadline for new libraries and breaking changes has passed. Upcoming dates: 1-Apr Boost 1.73.0 closed for major changes 8-Apr Boost 1.73.0 closed for beta ASAP Boost 1.73.0 beta 22-Apr Boost 1.73.0 closed for release ASAP Boost 1.73.0 release "ASAP", in this list, means "As soon as possible after the preceding milestone" -- Marshall

1 0

[geometry] Planning switch to C++11
by Mateusz Loskot 26 Mar '20

26 Mar '20

Hi, We are planning to switch Boost.Geometry to C++11 https://github.com/boostorg/geometry/issues/590 Is the following procedure sensible: 1. Warn users on the Boost mailing lists about the planned switch to C++11 2. Make the switch (update the codebase) 3. Release the Boost.Geometry as C++11 e.g. with Boost 1.75 4. Announce on the Boost mailing lists that Boost.Geometry requires C++11 Are there any recommendations or requirements on how we should proceed? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

7 16

[GSoC 2020] Proposal Review for Boost.Multiprecision
by aman mahansaria 26 Mar '20

26 Mar '20

Hello Boost Team, I have prepared my draft proposal for Boost.Multiprecision project on Extending and optimizing the library for thousands of bits. The link for the same is: https://docs.google.com/document/d/1BgDtR2VCoxq0FFPCyK50l6crG9GMrTKkDYDCRoi… Please kindly provide your valuable feedback on the same. I had also submitted the same for review on the GSoC site as well. Let me know in case there is any issue with viewing of the document. Thanks and Regards, Aman Mahansaria First Year M.Tech CSE, NIT Trichy

2 1

[GSoC 2020] Proposal Review for Boost.Multiprecision
by Ram Nad 26 Mar '20

26 Mar '20

Hello Everyone, I have prepared my draft proposal for Boost.Multiprecision project on Extending and optimizing the library for thousands of bits. Here is the link, https://docs.google.com/document/d/1C0GkLYGuBjLvIdp-NvGJAjxwtUvY7xfNGxOlaOW… I have been in touch with the potential mentors of this project for quite some time now. This proposal is result of my discussions with them. Please kindly provide your valuable feedback on the same. P.S. I have also submitted the same for review on the GSoC site as well. Also, please let me know if there are some visibility issues or comment access is not working. Thank you Ram Nad Second Year CSE Undergraduate Indian Institute of Information Technology, Sri City

2 2

[gsoc20] Proposal review for extending Boost.Multiprecision to higher precision
by dim131 26 Mar '20

26 Mar '20

Hi Boost community, I have prepared a draft of my proposal for extending and optimising Boost.Multiprecision to higher precision, after an initial discussion with Christopher Kormanyos: https://docs.google.com/document/d/100he6gJnUCilhsEiRWaL7PYi0IZaAL4tJfu-D3y… Any feedback will be greatly appreciated. Thank you, Dim131 -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

3 3

[lightweight_test] cpp_main convention
by Mateusz Loskot 25 Mar '20

25 Mar '20

Hi, I noticed this as popular convention across Boost libraries (e.g. endian) to deal with test cases that may throw or leak exceptions: int cpp_main( int argc, char* argv[] ) { test(); return ::boost::report_errors(); } int main( int argc, char* argv[] ) { try { return cpp_main( argc, argv ); } catch( std::exception const & x ) { BOOST_ERROR( x.what() ); return boost::report_errors(); } } Is there any reason to prefer that one over this one? int main( int argc, char* argv[] ) { try { test(); } catch( std::exception const & x ) { BOOST_ERROR( x.what() ); } return boost::report_errors(); } Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Preliminary release schedule for 1.73.0
by Marshall Clow 25 Mar '20

25 Mar '20

We missed the start of the release cycle for 1.73.0. Bad release managers. No biscuit. Here's my preliminary schedule for the 1.73.0 release: 25-Mar Boost 1.73.0 closed for new libraries and breaking changes 1-Apr Boost 1.73.0 closed for major changes 8-Apr Boost 1.73.0 closed for beta ASAP Boost 1.73.0 beta 22-Apr Boost 1.73.0 closed for release ASAP Boost 1.73.0 release "ASAP", in this list, means "As soon as possible after the preceding milestone" Please let me know if you see any problems with this. -- Marshall

2 2

Strange failure in regression matrix
by Alexander Grund 24 Mar '20

24 Mar '20

Hi, I got a failure of Boost.Nowide develop (and master) for msvc-14.0 in the regression matrix although that configuration is tested as far as I can tell. Furthermore there isn't any indication WHAT failed, see https://www.boost.org/development/tests/develop/developer/output/teeks99-09… Am I missing anything or is this a quirk of the regression tester? Thanks, Alex

1 0

Bug in Boost.Asio strand(strand<OtherExecutor>&& other)
by Niklas Gürtler 24 Mar '20

24 Mar '20

Hello, there is a bug in the Boost.Asio strand::strand(strand<OtherExecutor>&& other) move constructor as it tries to do an invalid cast on the wrong object. A friend declaration is also required to access the private members of the other strand. I submitted a PR https://github.com/boostorg/asio/pull/333 to address this issue. Regards, Niklas

1 0

[gsoc] Example of exceptional project proposal
by Mateusz Loskot 24 Mar '20

24 Mar '20

...as it is not Dear students, if you aim to submit proposals like this, then please don't bother polluting the GSoC space with such rubbish. Please, let's display some minimum of professionalism and respect to each other. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[GSoC 2020] Proposal Review
by Ayush Bansal 24 Mar '20

24 Mar '20

Hi Boost Community, I have prepared a draft of my Proposal for Boost.GIL's Project on Implementation of Image Processing Algorithms. I'd love to hear your comments on the same. Link to Proposal - https://docs.google.com/document/d/1JwHOxS6DG0c0GgvBnpSmvxz1PtgMMlrga9FJOyO… Please let me know you reviews :) Thank you and Regards Ayush Bansal Fifth Year Undergraduate Student Department of Computer Science and Engineering IIT Kharagpur LinkedIn <https://www.linkedin.com/in/ayush-bansal-b0727a116/>

4 5

[Optional] Merge to master
by Alexander Grund 24 Mar '20

24 Mar '20

Hi, can Boost.Optional be merged to master? There is even a CI failure on develop with a PR fixing this. So would be great if those could be merged shortly. Thanks

1 0

[config] Merging 'develop' to 'master' before the 1.73 release
by Edward Diener 23 Mar '20

23 Mar '20

Are the changes in config's 'develop' branch going to be merged to the 'master' branch before the 1.73 release ? The reason I ask is that a config 'develop' PR which I authored is a dependancy of the tti library, ans I can not merge the 'develop' changes of tti into 'master' unless those config changes also are merged to 'master'.

2 2

Re: [boost] Looking for Boost.uBlas data frames project GSoC mentors
by Tom Kwok 23 Mar '20

23 Mar '20

Hi CB, Thank you for your suggestions. I will continue with my proposal and start solving the competency test. David as of now still has not replied though. So I might need to request for mentorship for Boost uBlas data frame GSoC project here. Is anyone interested in offering mentorship and reviewing my proposal and questions? Best regards, Tom > On 19 Mar 2020, at 3:00 PM, boost-request(a)lists.boost.org wrote: > > Date: Wed, 18 Mar 2020 18:26:43 +0100 > From: Cem Bassoy <cem.bassoy(a)gmail.com <mailto:cem.bassoy@gmail.com>> > To: boost(a)lists.boost.org <mailto:boost@lists.boost.org> > Subject: Re: [boost] Looking for Boost.uBlas data frames project GSoC > mentors > Message-ID: > <CADrR+Fv8r8GrNFs-w_bvy2VBmDP6w0w+FOOOeDh0Rax02-gBEw(a)mail.gmail.com <mailto:CADrR+Fv8r8GrNFs-w_bvy2VBmDP6w0w+FOOOeDh0Rax02-gBEw@mail.gmail.com>> > Content-Type: text/plain; charset="UTF-8" > > Hi Tom, > > probably David will be the only mentor for the data frame project. I > suggest that you continue with your proposal and solve the competency test. > You can find the data frame code at > https://github.com/BoostGSoC19/data_frame <https://github.com/BoostGSoC19/data_frame> > > Last year I mentored two great students for the Tensor project > <https://github.com/BoostGSoC19/tensor/wiki <https://github.com/BoostGSoC19/tensor/wiki>>. This year I can only mentor > one student. > > Good luck, > CB

2 1

[GSOC] [boost.multiprecision] Regarding test cases.
by Abhay Yadav 23 Mar '20

23 Mar '20

Hello, In the project of Multiprecision Big Number Types I have completed programming competency test but I want to know how test cases for higher precision will be generated? Is there any platform where we can compare desired output with my output? It will be more helpful.for me for proceeding in this project.. Thank you Regards, Abhay Singh Yadav

3 3

[parameter][1.73] Library broken and unattended. Regressions and unmerged PR.
by Andrey Semashev 22 Mar '20

22 Mar '20

Hi, I'd like to draw attention to Boost.Parameter state. Since 1.71, it seems to be broken as described in these issues: https://github.com/boostorg/parameter/issues/91 https://github.com/boostorg/parameter/issues/97 The latter one was actually reported to me in Boost.Log, as this Boost.Parameter bug affected its users in a rather nasty way (the user's code silently compiles and has the wrong effect). For the latter issue I created a PR with a fix: https://github.com/boostorg/parameter/pull/99 which got no reply so far. The person who assumed Boost.Parameter maintenance and made the problematic changes, Cromwell D. Enage, is not responding, so the library is basically broken and unmaintained. I really don't want 1.73 to be released with a bug like the one affected Boost.Log, so I would appreciate if someone with merge permissions could merge my PR. If not, I will be forced to fork the library internally in Boost.Log for 1.73 (which I also really don't want to do). This would take care of my immediate concern. The other issue seems to be affecting users as well and I don't have the solution for it. Given that the library is unmaintained, it might be better to: 1. Move the current state of develop to a separate branch. 2. Revert master and develop to a state prior to Cromwell's commits that went into 1.71 (i.e. to the 1.70 state). This should take care of the Boost.Log issue as well, so it would be fine with me as well. Thanks.

2 2

github pull request process on non-owned submodule
by Jeff Garland 22 Mar '20

22 Mar '20

Sorry if this is obviously documented somewhere, but searches of mailing list aren't helping. I'm looking to submit a pull request for the icl library to remove dependencies on date_time compiled library -- in conjunction with changes to date_time on develop now. I've basically followed the cheat sheet on the wiki: https://github.com/boostorg/wiki/wiki/Getting-Started%3A-Cheat-Sheet but when I try to push my branch I get permission errors. Is there something I did wrong or is the icl repo setup wrong? Thx, Jeff jeff@jeff-mint193:~/dev/boost/libs/icl$ git push origin dt_nolib Username for 'https://github.com': JeffGarland Password for 'https://JeffGarland@github.com': remote: Permission to boostorg/icl.git denied to JeffGarland. fatal: unable to access 'https://github.com/boostorg/icl.git/': The requested URL returned error: 403

2 2

Fwd: Projects for GSoC 2020
by degski 20 Mar '20

20 Mar '20

---------- Forwarded message --------- From: degski <degski(a)gmail.com> Date: Sun, 1 Mar 2020 at 17:00 Subject: Re: [boost] Projects for GSoC 2020 To: David Bellot <david.bellot(a)gmail.com> Yes. On Sun, 1 Mar 2020 at 04:26, David Bellot <david.bellot(a)gmail.com> wrote: > It sounds a good idea to me. Would you like to propose a project and be a > mentor? > It would be great! > > David > > On Thu, Feb 27, 2020 at 8:19 AM degski via Boost <boost(a)lists.boost.org> > wrote: > >> On Wed, 26 Feb 2020 at 14:39, David Bellot via Boost < >> boost(a)lists.boost.org> >> wrote: >> >> > Hi Boost community, >> > >> > so far we received a few good contributions for projects for GSoC 2020. >> The >> > proposals are from our usual mentors but I'm surprised we don't have >> more >> > projects in data structures and algorithms. Most of what we have concern >> > numerical problems. It's great but I wish to see more diversity in the >> type >> > of projects we propose. >> > >> >> Maybe the suggestions put forward do solicit few 'other' proposals. For >> containers, f.e. there are many 'entertaining' and useful things to >> consider, segment tree, spaghetti stack, trie, binary index tree, beap, >> kd-tree, bkd-tree, disjoint-set, n-ary tree, etc etc, etc. >> https://www.geeksforgeeks.org/advanced-data-structures/ presents many >> different data structures, there also a section on algos. >> >> degski >> -- >> @realdegski >> https://brave.com/google-gdpr-workaround/ >> "We value your privacy, click here!" Sod off! - degski >> "Anyone who believes that exponential growth can go on forever in a finite >> world is either a madman or an economist" - Kenneth E. Boulding >> "Growth for the sake of growth is the ideology of the cancer cell" - >> Edward >> P. Abbey >> >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >> > -- @realdegski https://brave.com/google-gdpr-workaround/ "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey -- @realdegski https://brave.com/google-gdpr-workaround/ "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

3 7

binomial distribution setter function
by Kemin Zhou 18 Mar '20

18 Mar '20

This is my first time posting in this mailing list. Not sure how to post to the developer only mailing list after reading the document for mailing list for a good half an hour. If I posted in he wrong mailing please let me know and kindly provide the developer mailing list. I am looking at the binomial.hpp file. I need to use the binomial object in a loop which requires to have high performance. I am thinking constructing the binomial object each time in the loop would be less efficient than if I construct a single object, the each time reset the p parameter and use the object. I am not sure why the setter method was not provided. 296 RealType success_fraction() const 297 { // Probability. 298 return m_p; 299 } 300 void set_success_fraction(RealType p) { 301 m_p=p; 302 } Line 296 is the getter method, I added the setter method at line 300. -- Kemin Zhou 858 366 8260

4 4

Boost.Nowide Ready for release
by Alexander Grund 16 Mar '20

16 Mar '20

Hi all, after the discussion in January this year I took over maintenance of Boost.Nowide. First goal: Integrate all changes and requests that came up during review and as Github Issues including the docs. Second goal: Get extensive CI running with coverage especially on Windows (it is a mainly Windows library) Third goal: Iron out bugs, performance issues and incompatibilities. Of great help was my fork I prepared (and announced here) earlier but it was still an incredible amount of work. I can now say I'm done! I invite everyone to test it, (re-)review the code or check the docu for anything that's missing: https://github.com/boostorg/nowide One of the bigger changes was to make the library "less header-only" (it already required compilation on Windows when using iostreams). This was due to some required functions being considered extensions by e.g. MinGW/Cygwin and hence failing for consumers build with `-std=c++98` (or similar). This now works! Final note for those interested: The standalone (non-Boost) version and converter will be available later. Happy poking!

3 3

[gil] Broken bit-aligned pixel locator on MSVC++ 64-bit optimized builds only
by Mateusz Loskot 14 Mar '20

14 Mar '20

Hi, Over the last few months, intermittently I've been chasing a peculiar bug that has been revealing itself in failing checksum tests in GIL's test/legacy/image.cpp [1] since we started testing GIL with MSVC++ (VS2017, VS2019) with b2 toolset=msvc variant=release address-model=64 [1] https://github.com/boostorg/gil/blob/2ff2d31895dae665ef3e05d0496bc082470e22… The peculiarity of this bug is that it has not been observed using any of these compilers: - GCC: 4.8, 4.9, 5, 6, 7, 8, 9 - Clang: 3.9, 4.0, 5.0, 6.0, 7, 8, 9, 10 - XCode: 8.3, 9.0, 9.1, 9.2, 9.3, 9.4, 10 There is complete report [2], but I also decided to reach the list looking for any insights that may help me to understand what may be causing the bug. Complete repo [3] has GitHub Actions to build and run minimal_test.cpp test. [2] https://github.com/boostorg/gil/issues/447 [3] https://github.com/mloskot/boost-gil-checksum-bug This minimal_test.cpp (at the bottom) leaves out the checksum calculation and narrows the scope of the bug down to the `xy_locator` and advances of the iterators. The test basically is this: 1. Create 3x3 image based on bit-aligned BGR or RGB pixel (e.g. bgr121_image_t) 2. Fill image with red 3. Draw blue diagonal ``` bgr121_image_t img(3, 3); // ... fill img with `bgr121_red` pixels // draw blue diagonal auto v = view(img); auto loc = v.xy_at(0, v.height() - 1); for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // set blue pixel value ++loc.x(); // INCREMENT X FIRST --loc.y(); } ``` If the loop like this is compiled using either - `b2 toolset=msvc variant=release address-model=64 optimization=space` (/O1 /Ob2) - `b2 toolset=msvc variant=release address-model=64 optimization=speed` (/O2 /Ob2) then pixels of the blue diagonal are messed up. If the loop is compiled without optimization using either - `b2 toolset=msvc variant=debug address-model=64` (/Od /Ob2) - `b2 toolset=msvc variant=release address-model=64 optimization=off` (/Od /Ob2) then pixels of the blue diagonal are correct. Now, if the `for` loop above is modified, that is, lines incrementing the `x_iterator` and `y_itertor` are reordered: ``` for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // set blue pixel value --loc.y(); ++loc.x(); // PRE-INCREMENT X SECOND } ``` or ``` for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // set blue pixel value --loc.y(); ++loc.x(); // POST-INCREMENT X SECOND } ``` then the blue diagonal is drawn correctly regardless of the MSVC++ optimizations. If the loop is manually unrolled, see minimal_test.cpp below, the blue diagonal is correct too. I'm yet to try the CE to see compare the generated code, as far as my limited assembly fu goes, but currently Boost for MSVC++ on CE is broken (https://github.com/mattgodbolt/compiler-explorer/issues/1816) If anyone would have any insights on what may be causing the problem, or any suggestions what else to test, I would greatly appreciate that. Obviously, I'm getting suspicious about the MSVC++ optimizer, but I do know blaming a compiler is last+1 resort :) Thanks Mateusz ``` // minimal_test.cpp #include <boost/version.hpp> #include <boost/core/lightweight_test.hpp> #if BOOST_VERSION < 106900 #include <boost/gil/gil_all.hpp> #else #include <boost/gil.hpp> #endif namespace gil = boost::gil; #if BOOST_VERSION > 107200 using channel_sizes_t = boost::mp11::mp_list_c<int, 1, 2, 1>; #else using channel_sizes_t = boost::mpl::vector3_c<int, 1, 2, 1>; #endif using bgr121_ref_t = gil::bit_aligned_pixel_reference < std::uint8_t, channel_sizes_t, gil::bgr_layout_t, true > const; using bgr121_image_t = gil::image<bgr121_ref_t, false>; using bgr121_view_t = typename bgr121_image_t::view_t; using bgr121_pixel_t = typename bgr121_view_t::value_type; bgr121_pixel_t bgr121_red(0), bgr121_blue(0); void fill_image_red(bgr121_image_t& img) { gil::rgb8_pixel_t red8(255, 0, 0); gil::rgb8_pixel_t blue8(0, 0, 255); gil::color_convert(red8, bgr121_red); gil::color_convert(blue8, bgr121_blue); auto v = view(img); std::fill(v.begin(), v.end(), bgr121_red); for (auto it = view(img).begin().x(), end = view(img).end().x(); it != end; ++it) BOOST_TEST(*it == bgr121_red); } void test_draw_with_xy_locator_loop_fail(std::ptrdiff_t w, std::ptrdiff_t h) { bgr121_image_t img(w, h); fill_image_red(img); { auto v = view(img); auto loc = v.xy_at(0, v.height() - 1); for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // OPTION 1 FAILS ++loc.x(); // PRE-INCREMENT X FIRST --loc.y(); // OPTION 2 FAILS TOO //loc.x()++; // POST-INCREMENT X FIRST //loc.y()--; // OPTION 3 FAILS TOO //auto& x_it = loc.x(); // PRE-INCREMENT NAMED X FIRST //++x_it; //auto& y_it = loc.y(); //--y_it; } } { auto it = view(img).begin().x(); // row 0 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; // row 1 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; // FAIL BOOST_TEST(*it == bgr121_red); ++it; // row 2 BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); } } void test_draw_with_xy_locator_loop_good(std::ptrdiff_t w, std::ptrdiff_t h) { bgr121_image_t img(w, h); fill_image_red(img); { auto v = view(img); auto loc = v.xy_at(0, v.height() - 1); for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // OPTION 1 WORKS --loc.y(); ++loc.x(); // PRE-INCREMENT X SECOND // OPTION 2 WORKS TOO //loc.y()--; //loc.x()++; // POST-INCREMENT X SECOND } } { auto it = view(img).begin().x(); // row 0 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; // row 1 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; // row 2 BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); } } void test_draw_with_xy_locator_step_good(std::ptrdiff_t w, std::ptrdiff_t h) { bgr121_image_t img(w, h); fill_image_red(img); { auto v = view(img); auto loc = v.xy_at(0, v.height() - 1); *loc = bgr121_blue; // red red blue ++loc.x(); --loc.y(); *loc = bgr121_blue; // red blue red ++loc.x(); --loc.y(); *loc = bgr121_blue; // blue red red ++loc.x(); --loc.y(); } { auto it = view(img).begin().x(); // row 0 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; // row 1 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; // row 2 BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); } } int main() { test_draw_with_xy_locator_loop_fail(3, 3); test_draw_with_xy_locator_loop_good(3, 3); test_draw_with_xy_locator_step_good(3, 3); return boost::report_errors(); } ``` Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

[website] Update notes of historic releases
by Mateusz Loskot 11 Mar '20

11 Mar '20

Hi, Is this possible to update release notes of historic releases? I'd like to update notes of GIL for 1.69 which, as I found, have been never collected and are completely missing https://github.com/boostorg/gil/commit/2ff2d31895dae665ef3e05d0496bc082470e… Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

C++ Deflate (zlib-like) library
by Janson R. 11 Mar '20

11 Mar '20

Hello everyone, I have recently been working on a C++ compression library very similar to zlib after trying to implement some HTTP compression support over Boost.Beast and realizing after some discussion with sir Falco that while it would be a nice builtin feature for Beast, it would possibly be a better idea to have zlib-like compression be a separate library in order to be properly maintainable and likely more useful. The current working version can be viewed at https://github.com/ryanjanson/Deflate however the API could still be helped in terms of modern C++ usability, and what I currently have in mind can be found annotated here: https://gist.github.com/AeroStun/687ec9ca69404e26f8e02e5084926036 Do you thing that this could be useful to have as its own entity in the Boost environment? Any kind of feedback on the idea and the library is warmly welcome. Regards, Janson

14 58

boost thread strange behaviour
by Adham Sabry 08 Mar '20

08 Mar '20

hi , i am trying to learn executors and executors thread pools using with boost::async but i found strange behabiour when i make thread pool adaptor ea and submit tasks to it and make ea00 and submit tasks to it if i started ea with async , it automatically starts ea00 the attached file has the code i thought that async will only start the passed thread pool"adaptor" But i think there is underlying thing which gather all threads of different pools into single entity and starts them with any call to boost::async is this a bug??? i run this from windows 7 64 by visual studio 2017

3 7

[GSoC20] [Boost.Geometry] Seeking mentor for project 1
by João Tavares 07 Mar '20

07 Mar '20

Hello, I am a third year undergraduate student from IST - University of Lisbon in Applied Mathematics and Computer Science. I am very interested in the project 1 on the Boost.Geometry library. Having dealt with this sort of problem both on my university courses and on my own, in the context of competitive programming, I feel like I could contribute to this project during GSoC 2020. Regarding the competency test I have not been able to understand how or where it should be submitted. I am sending this e-mail to know whether there is someone willing to mentor me for this project. Thanks for the replies in advance. Best regards, João Tavares IST - University of Lisbon

2 1

ublas GSOC'20 Project
by Mrityunjay Tripathi 07 Mar '20

07 Mar '20

Hi everyone, I am Mrityunjay Tripathi, a 3rd-year Computer Science & Engineering undergraduate. I have been getting familiar with the boostorg/math and boostorg/ublas repositories for quite a few weeks. I find it quite interesting in terms of the functionalities they provide. But I see that the tensors section of uBLAS can be more improved by parallelizing the code using OpenMP and providing support for cuBLAS. I also wanted to add flexible NumPy/PyTorch tensor features such as autograd on tensors. Any feedback or suggestions are most welcome. Best Regards, Mrityunjay Tripathi

1 0

Hello!
by Kishan shukla 07 Mar '20

07 Mar '20

Hello Everyone! My name is Kishan Shukla, and I am a third-year undergraduate student of mathematics at IIT Kanpur. I am interested in contributing to Boost.real and have already sent two PR's https://github.com/BoostGSoC19/Real/pull/40 and https://github.com/BoostGSoC19/Real/pull/41, which are yet to be reviewed. Currently, I am stuck at a problem that I want to discuss with the mentors. Can I ask the project-specific issues here, or are there project-specific channels?

2 1

[build] ERROR: rule "[[bbv2.builtin.features.warnings]]`warnings`::" unknown in module "warnings-feature"
by Mateusz Loskot 06 Mar '20

06 Mar '20

Hi, (CC'ed to boost and boost-build) Two of Boost.Geometry users reported that peculiar error, [1] and [2] ``` /home/digu_j/boost/tools/build/src/tools/features/warnings-feature.jam:27: in load ERROR: rule "[[bbv2.builtin.features.warnings]]`warnings`::" unknown in module "warnings-feature". ``` and I'm having a hard time understanding what is going wrong here and what causes this issue, on Linux. The line 27 is a typical Jam line: ``` feature.feature warnings : on all extra pedantic off : incidental propagated ; ``` but this refers to something that puzzles me most ``` ERROR: rule "[[bbv2.builtin.features.warnings]]`warnings`::" unknown ``` a bit of comment block? ``` #| tag::doc[] [[bbv2.builtin.features.warnings]]`warnings`:: ``` Is this a parsing issue? Is this related to potentially existing system-wide installation of Boost.Build? If yes, why none of the dumps in [1] and [2] refer to any files in /usr? [1] ./b2 headers attempt https://github.com/boostorg/geometry/pull/667#issuecomment-584794370 [2] b2 attempt to build a program in libs/geometry https://github.com/boostorg/geometry/pull/665#issuecomment-595595900 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

[date-time] USE_DATE_TIME_PRE_1_33_FACET_IO to be removed in next release
by Jeff Garland 06 Mar '20

06 Mar '20

//crosspost from users list In case you've not checked the calendar (see below) it's 2020 and a the c++ world has moved on from the issue this macro solved. boost date-time also needs to move forward into the decade with a modernized all header code base . If you're dependent on this macro for any reason I'd like to hear about it. Thanks, Jeff using namespace boost::gregorian; date today = day_clock::local_day(); cout << today.year() << endl; //2020 ;)

1 0

Help: [Boost.GIL] setup
by R Rajiv 06 Mar '20

06 Mar '20

Hi I am Rajiv, a student whose looking to contribute to Boost's GIL library this year for GSOC 2020. I have read through the contribution.md page for setup of the environment for Boost.gil @ https://github.com/boostorg/gil/blob/develop/CONTRIBUTING.md. As I do not have cloning rights for the repo boost.git, I have forked and cloned my fork with --recurse-submodules.This leads me to the following issue: _______ fatal: repository 'https://github.com/rRajivramachandran/accumulators.git/' not found fatal: clone of 'https://github.com/rRajivramachandran/accumulators.git' into submodule path 'libs/accumulators' failed ________ I have been unable to proceed due to this issue. -- Thanks Rajiv

3 2

[program_options] Codecov failing on Travis CI for long time
by Mateusz Loskot 06 Mar '20

06 Mar '20

Hi, I've just submitted my first PR [1] to the library and Travis CI failed with: +lcov --gcov-tool=gcov-7 --rc lcov_branch_coverage=1 --base-directory /home/travis/build/boostorg/boost-root/libs/program_options --directory /home/travis/build/boostorg/boost-root --capture --output-file all.info Capturing coverage data from /home/travis/build/boostorg/boost-root Can't locate PerlIO/gzip.pm in @INC (you may need to install the PerlIO::gzip module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .) at /usr/local/bin/geninfo line 62. BEGIN failed--compilation aborted at /usr/local/bin/geninfo line 62. The command "ci/codecov.sh" exited with 2. I see this failure has been happening for a year now affecting all PRs from that period. I think it's desirable to keep the CI-s green, especially if there is no huge potential of breaking it as the library has not seen much activity. I can't offer a solution myself, but it may ring a bell to maintainer or someone else who knows how to fix it. [1] https://github.com/boostorg/program_options/pull/92 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

yabs: Yet Another Build System, seeking input/micro-team member
by degski 03 Mar '20

03 Mar '20

Hi All, Recently, I have started to get more and more dis-enchanted with Windows. The OS is being dumbed down every step of the way, while the internal complexity keeps going up. The latest and the most fun break-down to date of Windows was last week, the story is long, but in the end in came down to not being able to open the system-settings in the W10-style settings. The W7-style settings are also available, but the API's are overlapping but neither is a super-set of the other, so no way to fix the settings, because the settings themselves are broken (had something to do with display-drivers), way to go MS. In the meanwhile W10 is sorted again, but the whole lot is just getting increasingly fragile, while Fedora is getting increasingly solid (no bt-headphone stuttering, while connected to wifi and look at that brightness/crispness of that Full HD screen I have never seen before under W10!), the latter not upping complexity (2'001 packages to download and install to get from F30 to F31, but that's not complexity). I want to move to Fedora, and for now I'm dual-booting. This involves dumping VS in favor of VSCode (which is flat-packed for Fedora and compadres and is also available on OSX, so there is potentially a large audience), no acceptable other options (other than the one(s) VSCode is based on) are available AFAIKS, gnome-builder seems to have different goals from VS and it appears to be early days. VSCode seems (to me) to be like the best thing since sliced-bread, iff you are writing Python or Rust (Prolog works nicely as well), but C++ is only partially great, the language server works very nicely, code completion, good, but the build-system, proposed, is cumbersome. I would like VSCode to work more like VS, but without the complexity, the endless clicking, drop-down boxes etc etc. It comes down to writing json-files, which is good, but on a per project basis. Having to do this on a per project basis is a problem (that's going backwards from using project-templates in VS, I now in VS can create a new project in 3 seconds flat, and every detailed setting (clang and vc) is set correctly and how **I** want it, and I am running "Hello World!" (the default main in the template) in total 10 secs, this very handy to try things out). I don't want to go backwards. Therefore, I would like to do this on a repo-basis (the only one I have), with, iff required, another json in the project-folder (in the parent repo-folder), i.e.: /repos/ /repos/repo.json /repos/project-one/ /repos/project-one/project.json /repos/project-two/ /repos/project-two/project.json /repos/ ... I (want to) use vcpkg. I structure my projects always the same, all build systems (to my purpose) are basically an over-shoot on the one hand and overly fiddly on the other hand. The task at hand, build the .cpp files in the root of the project folder into one binary. The include files are either in the vcpkg/installed/.../include folder or in a sub-include-folder in the project. Libraries to link are either in vcpkg/installed/.../lib, or vcpkg/installed/.../debug/lib. We are not talking rocket-science here, I presume that many people have simple needs like this/me, or that if building (adopting this structure) becomes easy enough people would adopt such a structure. I would like to have one json to rule them all, and one json to either over-ride the defaults, or to add to the defaults, depending on whether the setting is defined in the repo.json. The repo.json might well be layered itself, to accommodate the various compilers, and/or configuration. For the moment nlohman's json seems perfectly adequate for the job, and it's certainly easy to use (and seems to just use std::maps in a clever way, so it's easy to follow what's going on). It's all about merging, fusing, overlaying those json's as needed (gonna be entertaining, making it smart), and pass that on to some generic API for building. So a new compiler would mean to just add a json-section, or a json-file, fill that with appropriate data (possibly nothing, iff the default-defaults are good), and it should work. The current way VSCode is setup, means that this imaginary build-system can be easily and readily included/used in VSCode (with more json). Yes, just like the working name indicates YABS, it must be as simple as possible, but no simpler. Any input is appreciated, but please refrain from arguing that BS-X does this better (and exists) or BS-Y has a large crowd of followers (and is used for a long period of time), that's water under the bridge, I will pursue this, just to see how far one can get pushing these initial ideas further. As usual my write-ups are a bit messy, I am learning I'm slightly dyslexic, sorry for the endless comma's. Thanks in advance for any ideas submitted. I would not mind partnering with somebody else, ya'll have a nice day, degski -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

1 0

Fwd: Boost.StaticString (formerly Boost.FixedString) is ready for release!
by degski 03 Mar '20

03 Mar '20

---------- Forwarded message --------- From: degski <degski(a)gmail.com> Date: Mon, 2 Mar 2020 at 23:14 Subject: Re: [boost] Boost.StaticString (formerly Boost.FixedString) is ready for release! To: Alexander Grund <alexander.grund(a)tu-dresden.de> On Mon, 2 Mar 2020 at 09:57, Alexander Grund <alexander.grund(a)tu-dresden.de> wrote: > Because if you use a signed type you have no compile-time guarantee that > the value is unsigned (using "type" and "value" to differentiate those 2). > You have indeed the guarantee that it is non-negative, compile-time, the problem is that, although you now know it is positive, you have lost (compile-time) any means of determining whether this value is correct (at run-time), while the guarantee at compile-time is just tautological. I don't understand really what you have against it, one can always use an int64_t, iff worried about int32_t overflow. Same as with a pointer: It can be NULL. > This value of null in itself is nothing special, it points at the top/bottom of the stack, there's nothing, so we hit UB. I don't think this is a good parallel. Pointers are not numbers, addition is meaningless. Adding up sizes is not meaningless, and we do it every day. Adding (or deducting) up a size and a pointer-difference is not meaningless either, that's why size needs to be signed. > If you want an interface where you want to guarantee at compile-time that > the value passed over an API is never NULL, you use e.g. a reference that > can never be NULL (or not_null<T>) > Herb's most recent post puts another angle on this: http://herbsutter.com/2020/02/23/references-simply/ . > > >> Didn't you argue in the mail before that there will never be anything of >> size 2^32 and hence even not anything like 2^64? How could you overflow >> that then? >> > > If you are manipulating (subtracting, adding differences) pointers, I > thought I wrote that. The pointers might be pointers into Virtual Memory > and can have any value [1, 2^56]. > > Not sure I understand that. Can we agree that a 64-bit unsigned type is > big enough to store any size of any container and hence no overflow is > possible? > Yes, certainly, what about a 63-bit value (the positive part of a signed 64-bit int), is that too small? ... signed type which may be an unsigned value. You'll have to check. > No, a signed value is never an unsigned value in disguise (that would result in overflow), the other way around, yes. I disagree. And as mentioned you can do things like `int difference = > int(obj.size()) - 1` anytime you want to do operations that are not fully > defined on unsigned types (as in: may result in values outside the range) > same as you can't to `int foo = sqrt(integer)` because you may get an > imaginary number (if sqrt could do that, but I think you get the gist). > C++ has questionable math's. How is that any different from `assert(a <= size); return size - a;`? > That's not what you wrote earlier. The you introduced a branch in release and made the function throw. > > all that because it upsets you that something that should not occur in > the first place in correct code can occur iff one is writing code that now > (as one observed it got negative) is known to have a bug. > > Again: How is that different to using a signed type for "size"? You have > exactly the same potential for bugs. You always have to make sure you stay > in your valid domain, and a negative size is outside of that valid domain. > Hence you got to check somewhere or use control flow to make sure this > doesn't happen. So no difference in signed vs unsigned size regarding that > The unsigned cannot overflow, that is not a bonus, that's a problem! > The use of unsigned is false security (actually no security) and serves > nothing. In the end, you still need to write correct code (so the signed > int's WON'T BE negative, there where they shouldn't be), but this practice > makes you're code less flexible, more verbose (the unavoidable casts add to > that) and probably slower than using signed. All that because of this > 'natural' way of looking at sizes. > > It serves as a contract on the API level: "This value is unsigned. > Period." > No, it says, if the value is out of the problem domain, don't worry, I'll cover it up (behind you're back so your app appears to be working, I make sure of that at compile-time). If the type was signed you'd need something else to enforce that the value > is unsigned. So yes you still need to write correct code and passing a > negative value to an API expecting an unsigned value is in any case a bug. > Of course, I never said, quite the opposite, that one not needs to write correct code. > Surely at runtime. How else could you guarantee that your value isn't > negative after you subtract something from it? It can be compile-time if > you only add something to it and ignore overflow but you already do that > when using signed values anyway. > > So, why does it need to be guaranteed positive at compile time? It just needs to be positive (size) at run-time, and as per above, you'll have to check. > But all this arguing doesn't solve much: What piece of code would actually > benefit from having a signed size? > I have already spelt out the reasons in an earlier post in this thread. > And not only the part where you request the size and use it, but also the > part where you give that size back to the object, so you'll need to ensure > an unsigned value. And yes `for(int i=0; i<int(obj.size())-1; i++)` is a > known example that would allow to get rid of the cast if the size was > signed. But again: That is due to operation used. `for(unsigned i=0; > i+1<obj.size(); i++)` is perfectly valid assuming no overflow > Thou shall not compare signed and unsigned values, my compilers insist and keep on telling me that. So now you need a cast to shut the thing up, and I would write: for ( int i = 0, back = static_cast<int> ( obj.size ( ) ) - 1; i < back; ++i ). I would like: for ( int i = 0, back = obj.size ( ) - 1; i < back; ++i ). This is my last post on the subject (bar new arguments). Thank you for the discussion. degski -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

2 2

Boost.StaticString (formerly Boost.FixedString) is ready for release!
by Krystian Stasiowski 02 Mar '20

02 Mar '20

Hi all, After some post-review polishing, Boost.StaticString is good to go for release! I have been in touch with the review manager, and everything has been checked over. Repo: https://github.com/sdkrystian/static_string Docs: https://sdkrystian.github.io/doc/static_string Here are some things that have been changed post-review: - Library has been renamed from Boost.FixedString to Boost.StaticString. Class template fixed_string has been renamed to basic_static_string, and aliases have been added for common character types, similar to std::string. - constexpr support to the fullest extent supported by available compilers has been added. - Functions that will not throw have been marked noexcept. - Moved to a single header configuration. - std::hash and boost::hash_value support has been added. - It has been decided that functions will throw on capacity overflow. - A specialization for when the capacity is 0 has been added that has no member. Additionally, the type of the member used to store the size of the string is now statically chosen to be the smallest possible width unsigned standard integer type that can hold all the needed size values. - operator+ has been implemented. - Floating point conversion support has been added to to_static_string/to_static_wstring. - Lots of bugs fixed. More behind the scenes, a bunch of optimizations have been added, taking advantage of the fact that the capacity is part of the type and known at compile time. Again, thank you all who participated in the review, and thank you Joaquin for managing it! Regards, Krystian Stasiowski

7 16

Projects for GSoC 2020
by David Bellot 01 Mar '20

01 Mar '20

Hi Boost community, so far we received a few good contributions for projects for GSoC 2020. The proposals are from our usual mentors but I'm surprised we don't have more projects in data structures and algorithms. Most of what we have concern numerical problems. It's great but I wish to see more diversity in the type of projects we propose. We want to attract the best students around the world and push toward new C++ standards and improvements of what we already have. Being a mentor is a great experience and on top of it, without too much effort, you will get someone of quality working for you during all the summer. The wiki page for projects is here: https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code%3A-2020 Please come, edit and contribute. Cheers, David

2 2

What is the right way to close and clean boost::log
by JH 01 Mar '20

01 Mar '20

Hi, I built boost::log in my application library, it created boost::log::sinks::synchronous_sink<boost::log::sinks::text_file_backend> and close it by calling the boost::log::core::get()->remove_all_sinks() in destructor of the Log library, then one of my application link to my log library got Segmentation fault when it exited: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff5fdd961 in boost::log::v2_mt_posix::core::remove_all_sinks() () from /usr/lib/x86_64-linux-gnu/libboost_log.so.1.65.1 If I add boost::log::core::get()->remove_all_sinks() in my application main before it return 0, the segmentation was gong, but it stuck. What is the proper right way to close and clean the boost::log? There is a blog suggested to run boost::log::core::get()->remove_all_sinks() when the main end, but that does not seem work. https://www.boost.org/doc/libs/1_62_0/libs/log/doc/html/log/rationale/why_c… Thank you. Kind regards, - jupiter

2 3

Cryptography for Boost.
by Mikhail Komarov 29 Feb '20

29 Feb '20

Hello! Cryptography for Boost. Again. It’s been some time since I’ve started developing so-called clean C++ cryptography implementation for my organization’s internal purposes. It was intended at first to be a cryptography framework fulfilling special cryptography schemes requirements, but eventually it has evolved into a full-featured suite, actively using and, sometimes, even based on Boost libraries. This turned out to be fine way to serve the Boost (and entire C++) community and to assemble a Boost version of a suite. So this letter is about wether there is still any interest in cryptography library for Boost and is there any sense to show the community what do I have for now? Sincerely yours, Mikhail Komarov nemo(a)nil.foundation

6 22

[gsoc] Encourage original ideas
by Mateusz Loskot 29 Feb '20

29 Feb '20

Hi, I noticed there may be confusion among students regarding project ideas. I sense, students (sometimes) fail to find the GSoC guides [1] ... So, based on the first paragraph of [1], I have updated our wiki [2] placing this note to students: "To any potential students, in addition to the list of project ideas, we don't discourage original ideas proposed by students. " If any mentors here disagree, please let me know and I will remove it (or move it to GIL, which I'm involved with as a mentor). [1] https://google.github.io/gsocguides/student/finding-the-right-project [2] https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code:-2020 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Who's using Boost
by Adam Getchell 28 Feb '20

28 Feb '20

Name: CDT-plusplus [1] Company: University of California Davis CDT-plusplus generates ensembles of quantum spacetimes under the Causal Dynamical Triangulations program using the Metropolis-Hastings algorithm, with other algorithms planned. These ensembles allow calculations of quantities such as the spectral dimension and the overall transition amplitudes from the beginning until the end of time for a simulated universe of given dimension and volume. Many different research problems may be answered with these ensembles, including the existence of a Newtonian limit in CDT [2], renormalization group flow in CDT, [3] and spontaneous dimensional reduction in short distance quantum gravity. [4] Where Boost is used: 82 Boost libraries are used in conjunction with CGAL [5] in order to perform accurate geometric and combinatoric operations on 3 and 4-dimensional Delaunay triangulations. Boost.Optional and Boost.Outcome are used to assist in correctness guarantees for billions of moves permuting triangulations on simulations running for months on High Performance Compute clusters. [6] [1] https://github.com/acgetchell/CDT-plusplus <https://github.com/acgetchell/CDT-plusplus> [2] https://ui.adsabs.harvard.edu/abs/2015APS..APR.X7006G/abstract <https://ui.adsabs.harvard.edu/abs/2015APS..APR.X7006G/abstract> [3] https://arxiv.org/pdf/1405.4585.pdf <https://arxiv.org/pdf/1405.4585.pdf> [4] https://arxiv.org/pdf/0909.3329.pdf <https://arxiv.org/pdf/0909.3329.pdf> [5] https://www.cgal.org/ <https://www.cgal.org/> [6] https://www.hpc.ucdavis.edu/ <https://www.hpc.ucdavis.edu/> Let me know if further information is needed. -- Adam Getchell, M.S. https://adamgetchell.org <https://adamgetchell.org/>

1 0

GSoC, Boost C++ and Slack channel
by David Bellot 28 Feb '20

28 Feb '20

Hi Boost community, we have a dedicated channel on Slack for all the discussions regarding the Google Summer of Code. Please join us on cpplang.slack.com on the channell #boost-gsoc. Cheers, David

5 4

Re: [boost] Cryptography for Boost.
by Kenneth Porter 26 Feb '20

26 Feb '20

--On Friday, February 21, 2020 6:21 PM +0300 Mikhail Komarov via Boost <boost(a)lists.boost.org> wrote: > It's been some time since I've started developing so-called clean C++ > cryptography implementation for my organization's internal purposes. It > was intended at first to be a cryptography framework fulfilling special > cryptography schemes requirements, but eventually it has evolved into a > full-featured suite, actively using and, sometimes, even based on Boost > libraries. This turned out to be fine way to serve the Boost (and entire > C++) community and to assemble a Boost version of a suite. How does it fit in with openssl and SASL? I'd been contemplating dipping my toes into a Windows email client and openssl has a native Visual Studio port but I don't know of one for any SASL libraries. So the available open source email libraries tend to be *nix-oriented and have to be built with a ported *nix toolchain.

8 8

Start with Boost Multiprecision
by Tarun Lahrod 25 Feb '20

25 Feb '20

Hello, I am Tarun Lahrod. An engineering undergrad who's willing to contribute to Boost Multiprecision library in GSoC 2020. Please help me where to start from. Even in the code base from where should I start it. I am very much interested in taking Multiprecision as a project. Please help me start. Thank you. Tarun Lahrod Computer Science and Engineering (CSE) Bharati Vidyapeeth's College of Engineering, New Delhi Linked In: www.linkedin.com/in/tarun-lahrod GitHub: github.com/tarunlahrod

2 1

Related to Boost.Real Project Proposal
by Vikram Chundawat 25 Feb '20

25 Feb '20

Hey everyone, I am Vikram Singh Chundawat. I have a decent programming experience in c++. I am interested in Boost.Real project proposal and I want to work on this project in GSoC 2020. I have good knowledge of data structure and algorithms. I am going through all references and blogs suggested on project site currently. I will prefer giving the competency test after 8 march as I have my exams till then. It will be great if you have any suggestions regarding the prerequisites of this project, till then i will be going through the resources given on the project page. Thank you Regards Vikram Singh Chundawat

1 0

[website] 1.72 Boost.Config docs are missing
by Andrey Semashev 25 Feb '20

25 Feb '20

Hi, On this page: https://www.boost.org/doc/libs/1_72_0/ following Boost.Config link: https://www.boost.org/doc/libs/1_72_0/libs/config/config.htm leads to 404 Page Not Found. I believe the correct link should be: https://www.boost.org/doc/libs/1_72_0/libs/config/doc/html/index.html

2 5

[GSoC] My piece of advice to students
by Mateusz Loskot 24 Feb '20

24 Feb '20

Dear Student, You are planning to participate in GSoC and develop some new features for the Boost libraries. Awesome! So, you want to introduce yourself to the community as soon as possible. Awesome! However, before posting your first question to the Boost mailing list, please, do read the official GSoC student guides [0]. All of it. [0] https://google.github.io/gsocguides/student/ I also recommend to read through other resources dedicated for students, especially this one from Google [1], one from a former student [2] as well as advice from Boost GSoC former student Louis Dionne [3]. [1] https://opensource.googleblog.com/2011/03/dos-and-donts-of-google-summer-of… [2] https://medium.com/@akshikawijesundara/google-summer-of-code-dos-and-do-not… [3] https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code%3A-Advice-From-… Once you get through the general GSoC materials, it's a good idea to start browsing Boost resources, from intro [3] through netiquette [4] to wiki [5]. On [3] and [5] you will find links to past and current project ideas for Boost libraries. Browse it, read it, and learn what kind of projects Boost community develops during GSoC. Start thinking about what interests you, which Boost library, which project, what you'd like to develop as GSoC student. [4] https://www.boost.org/community/gsoc.html [5] https://www.boost.org/community/policy.html [6] https://github.com/boostorg/wiki/wiki Meanwhile, it's a good idea to "Make First Contact" [0]. Subscribe to the boost (developers) and boost-user or library-specific mailing list at https://lists.boost.org join Boost channels on Slack at https://cppalliance.org/slack/ and start discussing your participation, project ideas, etc. Although the student guides [0] use the phrase about "communicating directly with potential mentors", it does NOT mean exchanging private e-mails with mentors asking "Are you interested to mentor me?". GSoC does not work this way. In my opinion, the word "directly" means to interact directly with the community where, obviously, potential mentors are members too. The Boost organization and mentors will have chance to select students and projects they wish to mentor during the selection process - a secret, you can learn about it from GSoC guides for mentors [8]. Yes, the selection is a competitive process. [8] https://google.github.io/gsocguides/mentor/selecting-a-student Next, start discussing project of your interest, start asking questions, investigate ways to contribute to Boost, start working on competency tests Mind you, competency test is Boost way to verify minimum necessary skills. I personally think Boost should also ask for a bug fix [2] explains: "Some organizations make it a must for you to fix a bug in their code base before submitting a proposal but some do not. Your chances are always high if you can fix a bug in the code." Submitting a pull request with a small feature is also a good idea, something to discuss with mentors/maintainers of library of your interest Pull requests will allow you to gain hands-on experience with workflow of peer reviews, continuous communication, addressing problems, testing your solution, using the infrastructure, being exposed to stress of 'annoying' requests from maintainers to fix this, tweak that... :-) For example, it worked well for Boost.GIL (you can PRs at https://github.com/boostorg/gil) "you have to go early even if you go to hell" [2] GSoC IS hard work! Make sure to start early, to take a proactive stance, to do your homework before you start asking questions, to expect no babysitting. Imagine the GSoC runs back in times when there is no StackOverflow, no web archives, no web search,... There really is no excuse for not searching the web first nowadays. Even compilers can do that! https://arxiv.org/abs/1906.11456 "To grow in life, be willing to suffer" ~David Goggins Have a great time during GSoC and good luck! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[static_string] Boost.StaticString (fka FixedString) accepted into Boost
by Joaquin M López Muñoz 24 Feb '20

24 Feb '20

Hello, Boost.StaticString (formerly known as FixedString) was accepted into Boost subject to the resolution of a number of issues I listed as priority 1: https://lists.boost.org/Archives/boost/2019/12/247820.php I've checked with the author that these issues have been already solved, so Boost.StaticString is good to go as an official Boost library (hopefully in time for shipping with 1.73). Thanks to Krystian and Vinnie for their work. Welcome Krystian to the dubious club of Boost authors :-) After the hard work needed to get the lib in, now comes the not less hard part of keeping it updated and generally healthy. Best regards, Joaquín M López Muñoz Review manager for candidate Boost.FixedString (now Boost.StaticString)

4 3

[gsoc2020][Boost.GIL] Advice needed regarding competency.
by sarthak 23 Feb '20

23 Feb '20

Hi everyone, I am Sarthak, a second year undergraduate engineering student. I wish to contribute to boost open source development during gsoc2020, specifically to Boost.GIL. But, I am not sure whether I am competent enough to contribute meaningfully to the organization (see the last point for precise question), I am hoping that someone here can give me advice regarding the same :) First, my reasons to contribute to boost - - I am reasonably proficient in programming (C++ included). I know I will be able to demonstrate it through programming competency test and all. In my day to day programming I normally do not use meta programming techniques which are prevalent in boost, this has made me more excited to work on boost because I will get to use these new fancy constructs :D - I just want to be part of open source community for once, sincerely. I have been using FOSS since forever and as a developer I have been longing to pay back, this is a good chance for me to do the same. - Why boost over any other organization? Largely because C++. I like the multi-resolution philosophy of C++ that you can get as close to machine as possible, or you can do high level manipulations through libraries and generics. More on that in proposal ;) - Why GIL (Project 1)? I want to learn image processing. Now this is where it gets tricky, the thing is that I am passionate about doing image processing, but I am not well versed with its theory. I have done a course on Signals and Systems in my university but that is pretty much it. This means that at the least I would need to learn image processing algorithms as we go on. Not that I hate it (on the contrary in fact) but that I am not really sure if it is possible at all for someone like me to contribute meaningfully during the few months of GSoC. I would love to hear from a mentor's experience of previous students on this. Honestly I would like to be rejected now if at all than after submitting my proposal with false hopes, or worse moving on with GSoC with such false hopes. I can also contribute to boost multiprecision in which I am substantially more experienced, but my first interest is in GIL and therefore if possible I would like to take the project in GIL. Any advice is appreciated. Thanks for reading. -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

Fwd: Open Source Hackathon Mentor Invitation
by David Bellot 23 Feb '20

23 Feb '20

A word from our friends doing C++ at Hackillinois Outreach... ---------- Forwarded message --------- From: Advai Podduturi <advai.podduturi(a)hackillinois.org> Date: Wed, Feb 19, 2020 at 7:56 AM Subject: Open Source Hackathon Mentor Invitation To: <david.bellot(a)gmail.com> Hello, My name is Advai Podduturi and I’m reaching out on behalf of the HackIllinois Outreach team. HackIllinois is a 36-hour collegiate Open Source hackathon that takes place annually at the University of Illinois Urbana-Champaign. This year, it will be from February 28th - March 1st, 2020. Our mission is to introduce college students to Open Source, while giving back to the community. We strive to create a collaborative environment in which our attendees can learn from and work with developers to make their own contributions. In past years, we’ve had developers from prominent projects such as npm, Rust, and Apache come to mentor students from our pool of 900+ attendees. We’d love it if you could pass along this message to the Boost C++ community or any individuals you believe would be interested. We will provide meals throughout the event and can reimburse for travel and lodging up to a certain amount depending on where in the US people are coming from. More information on mentorship can be found at hackillinois.org/mentor <http://ec2-52-26-194-35.us-west-2.compute.amazonaws.com/x/d?c=6287904&l=b31…>. You can also visit opensource.hackillinois.org <http://ec2-52-26-194-35.us-west-2.compute.amazonaws.com/x/d?c=6287904&l=360…> to see what kinds of projects were represented at our event last year. Sincerely, Advai Podduturi -- Advai Podduturi HackIllinois 2020 | Outreach Team advai.podduturi(a)hackillinois.org | 630-765-4099

1 0

[GSoC20] logo
by Pranam Lashkari 22 Feb '20

22 Feb '20

Our logo on the GSoC page[1] looks a little pixelated and small fonts are not readable can we replace it? I have attached a boost logo file in the mail and a transparent logo can also be found here[2] [1]: https://summerofcode.withgoogle.com/organizations/6011808097239040/ [2]: https://de.wikipedia.org/wiki/Boost_(C%2B%2B-Bibliothek)#/media/File:Boost.… Thank you, Pranam Lashkari

3 2

Extend and optimize Boost.Multiprecision to higher precision of thousands of bits or more.
by Shubham Agarwal 21 Feb '20

21 Feb '20

Hello, I read the documentation for the Boots.Multiprecision and found it interesting, and I'M willing to work on this for Gsoc. could you please help me to get started.

2 1

Boost. Multiprecision:Multiprecision Big Number Types
by Ashmita Singh 21 Feb '20

21 Feb '20

Hello everyone, I explored about this project and found it interesting and i am interested to work on it for GSOC 2020.Can someone please help me out in getting started? Thank you Ashmita Singh

2 1

GSOC2020
by Damian Vicino 20 Feb '20

20 Feb '20

Hi everyone, Boost is once again in Google summer of code! https://summerofcode.withgoogle.com/organizations/6011808097239040/ Thanks David and everyone participating in the proposal for this year.

2 1

Starting contribution at boost
by Ashmita Singh 14 Feb '20

14 Feb '20

Hello everyone, I am a beginner in open source contribution.I want to start my career in open source contribution with boost organisation.So please help me out with a project to which i can contribute.My preferred language is C++. Regards.

3 2

Boost geometry
by Shiko 13 Feb '20

13 Feb '20

Hello everyone. My name is Ahmed ElShreif and I'm a newcomer to the Boost community. I am willing to apply this year in GSoC with boost. I was accepted in LibreOffice in GSoC'19. I read the Projects and it's really interesting for me. But I have some questions: why this projects exist also in 2019 potential projects? Can I get help in finding some easy issues to solve now to get familiar with the library more and become ready more for the project? Thanks Ahmed ElShreif -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

Boost.Astronomy
by Eslam Tarek 13 Feb '20

13 Feb '20

Hello everyone. My name is Eslam Tarek and I'm a newcomer to the Boost community. I am willing to apply this year in GSoC with boost, But Ihave some questions: why this projects exist also in 2019 potential projects? Can I get help in finding some easy issues to solve now to get familiar with the library more and become ready more for the project? Regards, Eslam Tarek -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

Boost.Astronomy
by Eslam Tarek 12 Feb '20

12 Feb '20

Hello everyone. My name is Eslam Tarek and I'm a newcomer to the Boost community. I am willing to apply this year in GSoC with boost, I read the Projects and it's really interesting for me. But I have some questions: why this projects exist also in 2019 potential projects? Can I get help in finding some easy issues to solve now to get familiar with the library more and become ready more for the project? Regards, Eslam Tarek -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

1 0

If one specifies a cxxstd-dialect, one must also specify the cxxstd
by pbristow＠hetp.u-net.com 12 Feb '20

12 Feb '20

https://boostorg.github.io/build/manual/develop/index.html#bbv2.overview.bu… s.features says 5.3. Builtin features cxxstd Allowed values: 98, 03, 0x, 11, 1y, 14, 1z, 17, 2a, latest. cxxstd-dialect Allowed values: iso, gnu, ms. So these work as expected toolset=gcc cxxstd=2a cxxstd-dialect=gnu is OK toolset=gcc-9.2.0 cxxstd=2a cxxstd-dialect=gnu is OK too But if I do NOT specify the cxxstd version - just toolset=gcc cxxstd-dialect=gnu for example: boost\libs\multiprecision\example>b2 float128_snips toolset=gcc-8.1.0 cxxstd-dialect=gnu address-model=64 release > .mp_float128_snips_gcc810_14_gnu.log Iboost/tools/build/src/build\feature.jam:1020: in feature.compress-subproperties from module feature error: assertion failure: [ set.equal "<cxxstd-dialect>gnu" "<toolset-gcc:version>8.1.0" : "<toolset-gcc:version>8.1.0" ] error: Expected: [ "true" ] error: Got: [ ] which had be puzzled for a while. Probably the even more common case of only having one compiler, say gcc, installed, and so not specifying toolset at all, confusingly behaves the same way? This is a perfectly reasonable behaviour, but this requirement might helpfully be documented. Or this more subtle than I understand? Thanks Paul

2 4

[docs] Eclipse Foundation standardising AsciiDoc
by Mateusz Loskot 12 Feb '20

12 Feb '20

FYI ---------- Forwarded message --------- From: Mateusz Loskot <mateusz(a)loskot.net> Date: Wed, 12 Feb 2020 at 09:21 Subject: Eclipse Foundation standardising AsciiDoc To: <boost-docs(a)lists.boost.org> Hi, Number of Boost libraries/tools use AsciiDoc as preferred documentation format, so I think this initiative may be of interest here https://www.eclipse.org/lists/asciidoc-wg/msg00001.html https://www.eclipse.org/lists/asciidoc-wg/msg00002.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[Boost.Real] Base Change Not Incorporated in Initializer List Constructors
by Jai . 12 Feb '20

12 Feb '20

The base change done during GSoC 2019 seems to have not been incorporated in the initializer list constructors, thus giving incorrect results. Regards, Jai

2 2

No release in calendar for 2020?
by Mateusz Loskot 10 Feb '20

10 Feb '20

Hi, Am I seeing it right that nothing has been scheduled for 2020 at https://www.boost.org/development/index.html or is there a problem with the calendar (or my browser)? What is the schedule of the Boost 1.73.0 ? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

4 5

GSoC 2020 application
by David Bellot 10 Feb '20

10 Feb '20

Hi Boost community, just to let you know that our application to Google Summer of Code 2020 has been submitted. Let's hope for the best now. To all potential mentors, please keep adding projects if you are willing to participate. It's a great program with great benefits for our Boost community. Best regards, David

3 2

[Boost Real] GSoC 2020 - Introduction
by Chirag Thakur 10 Feb '20

10 Feb '20

Hi everyone. My name is Chirag Thakur and I'm a newcomer to the Boost community. I want to contribute to Boost.Real. I have been an active participator in programming contests like ACM-ICPC and other online judges over the last two years and have good proficiency in C++. I want to get involved using Google Summer of Code 2020. How can I start? Regards Chirag Thakur

2 1

[Boost Graph Library] Possible succint data structure addition
by Joana Modesto Hrotko 09 Feb '20

09 Feb '20

Dear Boost community, I am a Master's student and currently working on my Master thesis. My Master Thesis consists in implementing the k2-tree data structure in C++ and one of the additional proposals for my thesis would be to integrate my code with the boost graph library.I believe this integration would bring great value to the boost library and also it would provide a better validation for my work. So my question is if this would be something of interest for the library to integrate with boost graph library. INFO ABOUT K2-TREE: The k2-tree have been proved successful to represent in a very compact way different kinds of binary relations, such as web graphs, RDFs or raster data. Binary relations can be an abstraction to represent the relation between the objects of two collections of different nature: graphs, trees, strings, among others. They can be used in several low-level structures within a more complex information retrieval system, or even replace one of the most used one: an inverted index can be regarded as a binary relation between the vocabulary of terms and the documents where they appear. Moreover, it can represent the relation between terms and web pages, or even social networks or the connection between the web pages in the Web, which is normally represented as a web graph. k2-trees have been also used in other scenarios, such as geographical and RDF data, or images. Brisaboa, Nieves R., et al. "Compressed representation of dynamic binary relations with applications." Information Systems 69 (2017): 106-123. Coimbra, Miguel E., et al. "On dynamic succinct graph representations." arXiv preprint arXiv:1911.03195 (2019). Thank you in advance for your attention Best regards, Joana Hrotkó

3 4

[graph] State of the README
by Mateusz Loskot 09 Feb '20

09 Feb '20

Hi, Today's post [1] about feature suggestion for the BGL made me browse a bit and noticed this curious notes in the README [2] "Bugs and feature requests can be reported through the Trac issue tracker (...) Here [3] is why Trac is still in use." Is this information up to date? Last (substantial) change to the README.md happened in 2016. The Trac use rationale linked [3] from the readme is from 2015. [1] https://lists.boost.org/Archives/boost/2020/02/248164.php [2] https://github.com/boostorg/graph/blob/develop/README.md [3] https://lists.boost.org/Archives/boost/2015/04/221780.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

4 4

[Boost.GIL] GSoC 2020 - FFT implementation
by deb 06 Feb '20

06 Feb '20

Hi, I am a third year undergrad from IIT Bombay. I am interested in PROJECT 1: Image Processing Algorithms for BOOST.GIL . I have gone through the Getting started with Boost, Modular Boost Overview and Contributing page(on git repository for boost.gil) to get a fair idea of how Boost works. I went over the boost Gil library looking for an implementation of FFT(Fast Fourier transform) but could not find one . Since it is listed as a suggested project topic for the GSoC 2020 , I was hoping to implement it as part of my GSoC competency test. I have a few questions though:- a. Should I try and implement 1D-DFT(using FFT) independent from 2D-DFT (which is the more popular among image processing algorithms) ? b. Should I submit the above mentioned algorithms as separate PRs or as a single one? I am choosing FFT over other topics since it is an essential part of many image processing algorithms like Wiener filters, tomographic reconstructions etc. I have worked with image processing algorithms before on college projects and I think that I will be able to pull it off as a GSoC competency test. Thank You. Debabrata Mandal CSE undergrad, IIT Bombay -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

6 11

Boost_VERSION widely different between old CMake and new CMake find_package
by Dimitri John Ledkov 05 Feb '20

05 Feb '20

I have the following CMakeLists.txt: project(Boost CXX) cmake_minimum_required(VERSION 3.0) FIND_PACKAGE(Boost COMPONENTS filesystem REQUIRED) message( ${Boost_VERSION} ) In Ubuntu 18.04 LTS (Bionic) this produces: cmake ../ -- The CXX compiler identification is GNU 7.4.0 -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Boost version: 1.65.1 -- Found the following Boost libraries: -- filesystem -- system 106501 -- Configuring done -- Generating done -- Build files have been written to: /root/foo/build As in Boost_VERSION is set to 106501 In Ubuntu 20.04 LTS (Focal, devel release) which uses boost 1.71 with boost cmake files: -- The CXX compiler identification is GNU 9.2.1 -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found version "1.71.0") found components: filesystem 1.71.0 -- Configuring done -- Generating done -- Build files have been written to: /home/xnox/canonical/boost/debian/tests/srcs/filesystem/foo As in Boost_VERSION is set to 1.71.0 Now, lot of projects have Boost version comparison already and 1.71.0 is less than 106501. This creates problems for example when trying to detect and use new-style pythonXY components, filesystem v3 api, etc. For example I found in Ubuntu packages stanzas like: if (${Boost_VERSION} LESS 104400) Can we please fix Boost_VERSION in the new-style cmake to be compatible / same / similar / higher than the old Boost_VERSION string? -- Regards, Dimitri.

2 2

[Boost.GIL] GSoC 2020 Project 1 - Seeking Mentor
by Ayush Bansal 01 Feb '20

01 Feb '20

Hi, I am a final year undergraduate student from IIT Khraragpur. I was interested in the project “Image Processing Algorithms” to be developed during GSoC 2020. I was mainly interested in implementation of Morphological IP Algorithms, Normalising channels and De-noising filters. I have a good knowledge about most of these algorithms and have worked with a lot of them as a part of my BTech Term Project. In addition to the list of algorithms provided for morphology, I had some other filters which I think could be implemented easily such as - Boundary Extraction, Hole Filling, Thinning and Thickening algorithms. Similarly, for de-noising filters, I was wondering if filters such as Conservative Smoothing, Adaptive Filters etc. could be added to the list. For my competency test, I was interested in doing the implementation of convolution filter and use it to detect edges. However, I did not understand where should I be posting my submission for the same. I have done my previous internship at Google India, where I implemented my code in Google’s Production server in C++, thus I also have the experience of writing good industry level code. I wanted to know if someone would be willing to mentor me for this project. Thanking you in advance. Regards Ayush Bansal Fifth Year Undergraduate Student Department of Computer Science and Engineering IIT Kharagpur

2 10

[Boost.Real] Testing Boost.Real in Visual Studio
by Jai . 30 Jan '20

30 Jan '20

Hi, I would like to contribute to the upcoming Real library. I have cloned the library at BoostGSoC19/Real. I wanted to ask whether it is possible to directly test the library in Visual Studio, or do I have to use CMake to build the project first? Thanks, Jai

4 5

URL library?
by Vinnie Falco 30 Jan '20

30 Jan '20

Is there any interest in a URL library for Boost? This is something that has been requested for a while now, and I've finally gotten around to it. Key features: * Construct a read-only url::view from a string_view * Construct a modifiable url::value from a string_view - Mutate the parts (e.g. set_scheme) - Set encoded or decoded strings: url::value u; u.set_username("Fr ed"); u.set_encoded_password("pass%20word"); - Retrieve encoded or decoded strings: u.username(); // returns decoded std::string u.encoded_password(); // returns encoded string_view For servers, execution paths are provided to avoid all dynamic allocation. For example to retrieve the decoded username: url::static_pool<4000> sp; std::cout << u.username( sp.allocator() ); The std::basic_string returned by username() uses the specified allocator. A server can handle URLs without allocating any memory. There's some punycode conversion routines but I haven't figured out if they should be part of the library, or how they would manifest as APIs (for international domain names). You can perform calculations with URLs using an Allocator (default to std::allocator<char>), or you can use a container with "static storage" (e.g. fixed_string): url::static_value<4000> u; // 4000 char capacity The library is here: <https://github.com/vinniefalco/url> This is still a work in progress, and I'm open to feedback that might help me make better remaining design choices. Thanks

8 23

Re: [boost] Yet Another Container: DynamicArray
by Gavin Lambert 29 Jan '20

29 Jan '20

At 19:02 29/01/2020, Glen Fernandes wrote: >You shouldn't expect that. For any unique_ptr<T, D> you can only >expect that .get() gives you a D::pointer. For default_delete<T> >this might be T*. But it always depends on the Deleter. That seems like a significantly more annoying interface than std::shared_ptr uses. shared_ptr can hold fancy pointers too, but it happens explicitly via using fancy<T> rather than plain T, so the explicit indirection on usage is obvious too. Having that be an implementation detail of the deleter changing the effective "type" of the first template argument (which is what people think of as the type of the pointer, even if the standard disagrees) seems quite annoying. Maybe we should have a type-erased unique ownership pointer as well. I know the reason why we didn't was to avoid heap allocation or wasted storage for the common case, but there ought to be some happy middle ground. >The correct way to get a raw pointer from any >potentially-fancy-pointer x is: to_address(x) > >This can be boost::to_address (C++03 or higher), or >std::to_address (C++20 or higher) Hmm. This is news to me; I don't think I've read about it anywhere in conjunction with unique_ptr. Perhaps since it doesn't actually exist yet (most compilers are still mostly C++17). But eg. <https://en.cppreference.com/w/cpp/memory/unique_ptr>https://en.cppreference.com/w/cpp/memory/unique_ptr appears entirely mute on the topic. (There's a passing reference to fancy pointers but even that doesn't talk about it.)

3 2

Re: [boost] unique_ptr<T, D> and D::pointer and fancy pointers
by Glen Fernandes 29 Jan '20

29 Jan '20

Gavin, in case my explanation in that earlier reply wasn't clear: Given std::unique_ptr<Foo, D> p; 1. Users know that *p and p->x do the right thing by Foo. 2. p.get() will get them a D::pointer. This D::pointer might be Foo*, or it might be offset_ptr<Foo> or it might be alloc_ptr<offset_ptr<Foo>> or any other pointer-like type. To get a Foo* out of p.get() regardless of which of the above three it returns, you can call: Foo* q = std::to_address(p.get()); // C++20 in std, C++03 in boost Or, if you know that p is not a null pointer, you can also use: if (p) { Foo* q = std::addressof(*p); // C++11 in std, C++03 in boost } std::unique_ptr<T, D> was always designed for this (since C++11). Because not all pointers we use are raw pointers. An Allocator::pointer might not be X*, it might be offset_ptr<X>, or it might be aligned_ptr<offset_ptr<X>>. This property of unique_ptr is also unrelated to allocate_unique (which just leverages this with a fancy-pointer around the Allocator::pointer which in turn might be a fancy-pointer). But even today, users are using unique_ptr with non-raw pointers (like Allocators where Allocator::pointer is offset_ptr<X> instead of X*). They don't assume that p.get() returns a raw X* pointer. This might be a lesser known property of unique_ptr to some (especially those that do not work much with custom allocators), but this is the way it has always been and intentionally so. Glen

1 0

Yet Another Container: DynamicArray
by Christian Mazakas 29 Jan '20

29 Jan '20

I've been working on an AllocatorAwareContainer called `dynamic_array` and was wondering if there'd be any interest in including it in Boost. First and foremost, a link to the source code: https://github.com/LeonineKing1199/sleip `dynamic_array` is a heap-allocated array that can't be resized (without entirely re-assigning it). It's useful in cases where you'd normally use `std::vector` but have no need of `push_back`, `emplace_back`, or any of the other size modifiers that the container supports. These kinds of arrays are typically useful in I/O applications which normally only accept a pointer-size pair to write out to. Naturally the question arises, "why use `dynamic_array` in the year 2020 when we have `std::vector` and `boost::allocate_unique`?". `std::vector` imposes a constant storage cost of pointer, size, and capacity. `dynamic_array` only stores a pointer and a size making it slimmer in use-cases where there's no need of a separation between size and capacity. `dynamic_array` also supports constructors `std::vector` doesn't have. For example, `dynamic_array` is constructible from a Range and has a `noinit` constructor. `dynamic_array` even supports array objects which gives it another advantage. `boost::allocate_unique` is a significantly tougher class to beat because it boasts many of the same features: a dynamic allocation done using the supplied Allocator supporting `noinit` construction and array objects with a size (stored in the Deleter of the returned `std::unique_ptr`). And while it is true that `boost::allocate_unique` enables all of this, it still lacks a few key semantics. Namely, `dynamic_array` is copyable. It's also copy assignable and move assignable, including the case where the underlying allocators do not use the same memory resource and will instead perform a piece-wise move of the elements. It's arguable whether or not `std::unique_ptr` should support similar semantics so in the interim, `dynamic_array` is the next best thing. - Chris

8 25

[Boost.Config] Should BOOST_FORCEINLINE depend on NDEBUG?
by dariomt＠gmail.com 29 Jan '20

29 Jan '20

Right now BOOST_FORCEINLINE does not depend on NDEBUG. This means that on Debug builds the code asks to be forced-inlined with optimizations disabled, which does not make much sense to me. This is reflected by a myriad warnings in msvc under level 4 warnings. In fact Multiprecision library works around this issue by defining their own macro BOOST_MP_FORCEINLINE which decays to just inline in Debug builds (boost/multiprecision/detail/number_base.hpp lines 25-29). I think this behavior should be adopted by BOOST_FORCEINLINE. I'm happy to do a PR if there is agreement from maintainers.

3 2

Re: [boost] Yet Another Container: DynamicArray
by Glen Fernandes 29 Jan '20

29 Jan '20

I wrote: > Yes quite. i.e. What you believe is not true about boost::allocate_unique. > > i.e. For auto p = boost::allocate_unique<T[]>(a, n); > assert(p.get().size() == n); > > This is because the unique_ptr stores a pointer adaptor around the > Allocator::pointer which also stores the size. > > So the pointer and size are stored together in the unique_ptr result. Note, that the size is only stored for allocate_unique<T[]>(a,n) but not for allocate_unique<T[N]>(a) since there the N is known at compile time. For auto p = allocate_unique<T[N]>(a); your p.get().size() will return N, but there's no need to store a size_t for N, so we don't. > To get the plain Allocator::pointer out of it you can use p.get().ptr() > > Or, for example, p.release().ptr() for someone who wants to manage > it themselves. Glen

1 0

New allocator that uses global memory
by Frederick Gotham 25 Jan '20

25 Jan '20

I propose a new allocator that uses global (i.e. static duration) memory. Here is my current experimental code: #include <cstddef> /* size_t */ #include <new> /* Only for bad_alloc */ static int this_translation_unit; /* This serves the same purpose as __FILE__ */ template<typename T, std::size_t t_capacity, std::size_t t_counter, int *t_file = &this_translation_unit> class StaticAllocator { protected: static T buf[t_capacity]; public: typedef T value_type; template<typename U> struct rebind { typedef StaticAllocator<U, t_capacity, t_counter, t_file> other; }; T *allocate(std::size_t const n) { if (n > t_capacity) throw std::bad_alloc(); return buf; } void deallocate(T *, std::size_t) { /* Do Nothing */ } }; template<typename T, std::size_t t_capacity, std::size_t t_counter, int *t_file> T StaticAllocator<T, t_capacity, t_counter, t_file>::buf[t_capacity]; using std::size_t; #include <vector> using std::vector; #include <iostream> using std::cout; using std::endl; auto main(void) -> int { vector< char, StaticAllocator< char, 4, __COUNTER__ > > v; v.push_back('a'); v.push_back('b'); v.push_back('c'); v.push_back('d'); for (auto const &elem : v) cout << elem << endl; vector< char, StaticAllocator< char, 4, __COUNTER__ > > v2; v2.push_back('x'); v2.push_back('y'); v2.push_back('z'); for (auto const &elem : v2) cout << elem << endl; // Now try the first vector again for (auto const &elem : v) cout << elem << endl; } The trick I'm using with "this_translation_unit" compiles just fine on GNU and Clang, however it fails on Microsoft because the variable has internal linkage. I'm sure this can be done another way using Boost preprocessor stuff. The preprocessor macro "__COUNTER__" is available on every C++ compiler I know of. Frederick P.S. This is my second idea to the Boost development list. My first one is "istream_iterator_limited".

2 1

boost/asio/awaitable.hpp including <experimental/coroutine>
by Paps Olo 25 Jan '20

25 Jan '20

Hi, i've been trying to get the coroutine chat example to work, but it seems that in 1.72 and 1.71 boost/asio/awaitable.hpp does not compile when BOOST_ASIO_HAS_CO_AWAIT has been defined. Is there something i overlooked (i've been away from Linux development for some years...) or is boost really broken with this define? Which version should i try, or is there any sense in trying to fix this myself? Best regards papsolo

4 4

Re: [boost] dynamic_*<T>
by Glen Fernandes 24 Jan '20

24 Jan '20

Alexander wrote: > So if T[] and T[N] are valid, then T[N][M] should also be. This increases the scope greatly but has an incredible difficult questions to answer: What would operator[] return? I don't have a good answer... Simple questions that already have an answer: The same way shared_ptr<T[N][M]> works today. :) Its operator[] returns element_type& So: auto p = allocate_shared<int[5][1024]>(alloc); p[3][675] = 8; auto q = allocate_unique<double[][2][3][4]>(alloc, size); q[index][1][1][1] = 0.95; Then: dynamic<int[5][1024], Allocator> a(alloc); a[3][675] = 8; i.e. Making it work for T[N] also automatically makes it work for T[N][M]. Glen

2 1

[license] Boost license question
by Edward Diener 24 Jan '20

24 Jan '20

If some compiler vendor takes a version of Boost and makes changes to that version of Boost to suit the particular compiler, while distributing that version with full source code as an optional part of some release of that compiler, does this mean that the code is now proprietary for that compiler vendor ? Or does the code still remain open source so that a programmer can use the changes made to update his own version of a Boost release or provide PRs to some later release of Boost based on the code in the compiler vendor's release ?

4 6

[Boost][GSoC]New algorithm for multiplication
by Debajyoti Dasgupta 23 Jan '20

23 Jan '20

Sir/Ma'am, I am highly interested in working on the multiprecision big number types . I wanted to propose that since In the proposed project there is an increase in precision from 1000 to 10000 decimal digit , we can implement toom-cook algorithm instead of the standard karatsuba multiplication.Toom cook algorithm has a complexity of O(n^1.465) which is quite faster than karatsuba multiplication O(n^1.58). Please share your views on this. Thank you

2 2

Willing to take part in GSOC 2020 with Boost.
by Ram Nad 22 Jan '20

22 Jan '20

Dear Mentors, I am a second year undergraduate student from India. I would like to work with Boost.Multiprecision library. I have completed Programming competency test and would like to familiarise myself with the code base. It would be really helpful if you could guide me on where to start. Thanks You Ram Nad

2 1

Anyone got AT commands work using asio serial port?
by JH 22 Jan '20

22 Jan '20

Hi, There are many boost serial port sample code out there, but none of them I can run AT command. I have a device connected to my ubuntu 18, I can run AT command on minicom to get correct response, but I could not get any AT response from boost serial port. Has anyone made it work? Thank you. Kind regards, - jh

5 11

New Boost Review Wizard: Mateusz Loskot
by Glen Fernandes 20 Jan '20

20 Jan '20

Our thanks to Mateusz for agreeing to help Boost with the formal review process. https://www.boost.org/community/reviews.html has been updated to say: > The role of Boost Review Wizard is currently played by: > * Mateusz Loskot (mateusz at loskot dot net) > * John Phillips (johnphillipsithaca at gmail dot com) > > Past Review Wizards (we thank you for your service): > * Ronald Garcia Glen

2 1

Optional library
by anshu khare 19 Jan '20

19 Jan '20

Hi I ran the following code: const std::string i = "some string"; boost::optional<const std::string&> str = i; cout << get_optional_value_or(str, "some other string") ; It gives the output as : some string Which is absolutely fine. But when I run const std::string i = {}; boost::optional<const std::string&> str = i; cout << get_optional_value_or(str, "some other string") ; The output is an empty string. Shouldn't it give "some other string as output" because if I run the same code with integer it gives the second parameter of get_optional_value_or() as output?

2 5

New Boost Review Wizard: Volunteers
by Glen Fernandes 18 Jan '20

18 Jan '20

We need a new Review Wizard to take Ron's place. The duties include coordinating with review managers, scheduling reviews, and updating the website accordingly. Or as https://www.boost.org/community/reviews.html#Wizard puts it: > * When a formal review is requested for a library: > ** Approve the review manager based on their participation in the Boost community, including the mailing list, previous reviews, and other forums. > ** Suggest a schedule, after checking (via private email) availability of the review manager and library author. > ** Finalize the schedule, once the review manager verifies the library is actually ready for review. > ** Resolve schedule slips or other issues with review managers and submitters. > * Maintains a schedule of both past and pending reviews, in the form of the Review Schedule web page. > * Resolves questions from review managers and library submitters, who sometimes want a third opinion on questions such as "Should we extend the review period because ...?" > * Monitors the general review process, and makes minor adjustments as needed, or queries the list about possible major adjustments. When we appoint the new Review Wizard, I can grant them access to boostorg/website and provide more details about how to update it. We would like someone who is a Boost library author or contributor if possible. Any takers? Glen

3 3

GSoC 2020 and Boost C++
by David Bellot 18 Jan '20

18 Jan '20

Hi Boost community, Boost C++ will apply again this year to be a mentoring organization for the Google Summer of Code. We are seeking mentors with good projects to join us and have the chance to mentor students from all around the world and contribute code to one of the Boost library. Applications for organization open tomorrow and are open until February 5th. We will apply as usual. In the meantime, help me and propose new projects, declare yourself as a potential mentors on the Boost mailing list and start editing the page at https://github.com/boostorg/boost/wiki/Google-Summer-of-Code%3A-2020 with your own project. Best regards, David

1 0

Potential Mentor's Interest in Boost GSoC2020
by Christopher Kormanyos 17 Jan '20

17 Jan '20

Dear Boost, A generic reminder that org applications GSoC 2020has reached me in another forum yesterday. I'm not the organizer of this, but a potential mentor.Do other potential mentors have suitable projectsand interest in mentoring? Based on previous years,interest this year seems less strong. But the timeto get involved is upon us. I posted one of my potential projects here: https://github.com/boostorg/boost/wiki/Google-Summer-of-Code:-2020 ...And it has remained alone for almost 1 week. Best regards, Chris

4 4

Extension of math/complex library
by anshu khare 17 Jan '20

17 Jan '20

Hi mentors, I would like extend math/complex library in which the user will be able to compute roots of equation like z^n - a =0 where n,a € R+. Example : z^4 - 1 = 0 Anshu

1 0

(no subject)
by anshu khare 17 Jan '20

17 Jan '20

I verified it when I ran Cout<<fixed<<setprecision(20) << cos(7*pi/2) << endl; The output of the above line came out to be -0.000 In the earlier code when the output came as -1. 06911e - 50, I thought it to be like (-50) + (-1. 06911e ) which seemed a highly negative value to me.

1 0

Incorrect values of sin and cos
by anshu khare 17 Jan '20

17 Jan '20

cos(3*pi(cpp_bin_float_50>()/2)) does not give correct value. Only cos(pi(cpp_bin_float_50>()/2)) gives correct value. All odd multiples of cos(pi/2) do not give correct value. The issue with sin() as well. Anshu

4 7

Future directions for Boost.Math and Boost.Multiprecision
by pbristow＠hetp.u-net.com 16 Jan '20

16 Jan '20

Trying to obtain some user (and potential user) feedback, and guidance on future work, a discussion at https://github.com/boostorg/math/issues/303 has been started. If you (or your friends and colleagues) have ideas for mathy things like 'special' functions, statistical distributions, tools like integration, curve fitting, signal processing ... that the current libraries do not meet, please feel free to contribute to this wish-list collection of ideas. (This is not, of course, a promise to implement everything or indeed anything! But might help us to focus work on areas that have most value to users.) Paul

3 2

Worked on issue 49
by anshu khare 16 Jan '20

16 Jan '20

Hi I have worked on issue 49 of core library. Should I pull a request regarding the same?

3 2

(no subject)
by anshu khare 16 Jan '20

16 Jan '20

cos(3*pi(cpp_bin_float_50>()/2)) does not give correct value.

1 0

Contribution to core library
by anshu khare 13 Jan '20

13 Jan '20

Hello mentors, I would like to contribute to the core library of BOOST. I am working on windows. I cloned boostorg/core library. After cloning I found that there are many folders. Could you please tell which folder should I look up? Thank you Anshu Khare

4 5

Documentation of dynamic cast
by anshu khare 11 Jan '20

11 Jan '20

Hello mentors, Could you please provide the documentation and code of dynamic_cast?

2 1

[Astronomy] GSoC2020
by Pranam Lashkari 10 Jan '20

10 Jan '20

Hello, Earlier I was thinking of resting astronomy library for this GSoC and bring it to its first formal review after some development on my own cause it has been part of GSoC for 2 years now and still not reached to its first review and there are still many pending things before its first review. Since last month, I have started receiving many requests and ideas from the students about this library and many students are taking initiative and this may speed up the process of development. I still would like to know the opinion of the community before including this library in this GSoC. Thank you, Pranam Lashkari

3 2

boost range for non integers
by Wim Leflere 10 Jan '20

10 Jan '20

Hello, I was wondering why the (i)range function is limited to integers. https://www.boost.org/doc/libs/1_72_0/libs/range/doc/html/range/reference/r… It would be nice if it also supported floats. Or any 'incrementable' class, e.g. Date. Regards, Wim Leflere

2 2

New allocator uses global memory
by Frederick Gotham 10 Jan '20

10 Jan '20

I propose a new allocator that uses global (i.e. static duration) memory. Here's my current experimental code: #include <cstddef> /* size_t */ #include <new> /* Only for bad_alloc */ static int this_translation_unit; /* This serves the same purpose as __FILE__ */ template<typename T, std::size_t t_capacity, std::size_t t_counter, int *t_file = &this_translation_unit> class StaticAllocator { protected: static T buf[t_capacity]; public: typedef T value_type; template<typename U> struct rebind { typedef StaticAllocator<U, t_capacity, t_counter, t_file> other; }; T *allocate(std::size_t const n) { if (n > t_capacity) throw std::bad_alloc(); return buf; } void deallocate(T *, std::size_t) { /* Do Nothing */ } }; template<typename T, std::size_t t_capacity, std::size_t t_counter, int *t_file> T StaticAllocator<T, t_capacity, t_counter, t_file>::buf[t_capacity]; using std::size_t; #include <vector> using std::vector; #include <iostream> using std::cout; using std::endl; auto main(void) -> int { vector< char, StaticAllocator< char, 4, __COUNTER__ > > v; v.push_back('a'); v.push_back('b'); v.push_back('c'); v.push_back('d'); for (auto const &elem : v) cout << elem << endl; vector< char, StaticAllocator< char, 4, __COUNTER__ > > v2; v2.push_back('x'); v2.push_back('y'); v2.push_back('z'); for (auto const &elem : v2) cout << elem << endl; // Now try the first vector again for (auto const &elem : v) cout << elem << endl; } The trick I am using with "this_translation_unit" works fine on GNU and Clang, however it fails to compile on Microsoft because the variable has internal linkage. I'm sure we can do this another way using something from the Boost preprocessor library. The preprocessor macro __COUNTER__ is available on every compiler I know of. Frederick P.S. This is my second idea posted to the Boost dev list. My first one was "istream_iterator_limited".

3 2

Willing to participate in GSOC'20 with boost
by soham mukherjee 10 Jan '20

10 Jan '20

Hi, I am Soham Mukherjee. I am willing to participate in GSOC-20 and was looking forward participating with this organization. Can someone please guide me on how to get started and linking me to some easy fixes and also documentations so that I can familiarize myself with the codebase. Thanks

4 5

Clone warnings in lexical_cast
by Tom Kent 09 Jan '20

09 Jan '20

I just ran a: git clone --recursive https://github.com/boostorg/boost boost_root and I got some warnings in lexical_cast: Cloning into 'D:/teeks99-09/boost_root/libs/lambda'... Cloning into 'D:/teeks99-09/boost_root/libs/lexical_cast'... warning: unable to unlink 'D:/teeks99-09/boost_root/.git/modules/lexical_cast/objects/b1/102161720ea50668a5756828409400a4314744.temp': Invalid argument warning: unable to unlink 'D:/teeks99-09/boost_root/.git/modules/lexical_cast/objects/8a/0a6c194259a9a3fa24ea3fb815899bfcbfed64.temp': Invalid argument warning: unable to unlink 'D:/teeks99-09/boost_root/.git/modules/lexical_cast/objects/47/dd68ef6ee5c02257a57d03ac9e611a68893d0d.temp': Invalid argument warning: unable to unlink 'D:/teeks99-09/boost_root/.git/modules/lexical_cast/objects/02/b86ef5bcc4574e5c03b75ed463dbb5ada446c9.temp': Invalid argument warning: unable to unlink 'D:/teeks99-09/boost_root/.git/modules/lexical_cast/objects/c2/b4875ef060ea7de75feceb1f20284766128325.temp': Invalid argument Cloning into 'D:/teeks99-09/boost_root/libs/local_function'... I don't think these are an issue necessarily but it might be something that can be cleaned up. Tom

2 1

[Graph] Large incoming changes to Boost.Graph master.
by John Maddock 08 Jan '20

08 Jan '20

Dear all, Boost.Graph has had no maintainer for some time, but the CMT has been busy fixing bugs none the less. Unfortunately, other than some trivial fixes to docs and some directory refactoring, nothing much has been merged to master in a good while . On the plus side, develop is now in a better tested tested state than IMO it has ever been, however the change set is rather large so the potential to mess up somebodies code is certainly there: https://github.com/boostorg/graph/pull/196. So... this is both a heads up, and a plea: if you have any mission critical code using the Graph library, could you please test against current develop and report any problems? If you don't want to mess about with git, download from https://github.com/boostorg/graph/archive/develop.zip and place zipfile-contents/libs/graph/include in your include path ahead of that for Boost-1.72. Many thanks, John.

1 0

What happened to Boost.Nowide?
by Alexander Grund 08 Jan '20

08 Jan '20

Hi, I'm a user of (a fork of) Boost.Nowide and already fixed some issues I found and was looking into getting them upstream. I also wanted to know, if it is finally in Boost. Unfortunately this does not seem to be the case. I found https://lists.boost.org/Archives/boost//2017/06/236475.php which accepted it into Boost. This is from mid-2017 and nothing has happened since. Does anyone know what the status of Boost.Nowide is? It seems the filestream parts are now incorporated into Boost.FileSystem. So it seems only cin/cout/cerr, the args wrapper and the C-functions (fopen, ...) are missing. Especially the first 2 are very useful in writing cross-platform code. Might those be integrated into some other Boost Library? Thanks, Alex

4 16

Retirement as Review Wizard
by Ronald Garcia 07 Jan '20

07 Jan '20

Dear Boosters and Boost Steering Committee, After roughly 14 years as a Boost Co-Review Wizard, I feel that the time has come for me to step down from the position, and make room for a new face with fresh ideas. It has been my pleasure to serve in this position for this time alongside first Tom Brinkman and now John Phillips. I look forward to seeing what the next 14+ years of Boost brings! Sincerely, Ron Garcia Boost Co-Review Wizard

8 7

Query on Project Multiprecision/Math GSoC 2020
by Christopher Kormanyos 06 Jan '20

06 Jan '20

Dear Boost Is there a place to post and describe a potentialGSoC 2020 project? We have a potential project for GSoC 2020. It involvessignificantly extending the precision of Boost.Multiprecisionand harmonizing these extensions and tests with Boost.Math.I have the proposal worked out in plain text and would liketo post it or share it. We have discussed this project (in PM) with the knownrecent authors and maintainers of Multiprecision and Math,and interest is strong. On a personal note, my name isChristopher Kormanyos, previous three-time Boost GSoCmentor. In previous years, I have also contributed to bothMath and Multiprecision. Thank you and kind regards, Chris

1 0

Re: [boost] Recommended way of generating documentation
by pbristow＠hetp.u-net.com 06 Jan '20

06 Jan '20

> -----Original Message----- > From: Boost <boost-bounces(a)lists.boost.org> On Behalf Of Richard Hodges via > Boost > Sent: 1 January 2020 12:03 > To: boost(a)lists.boost.org List <boost(a)lists.boost.org> > Cc: Richard Hodges <hodges.r(a)gmail.com> > Subject: Re: [boost] Recomended way of generating documentation > > Treading carefully here as I'm new to boost library maintenance... > > > So that you can cross-reference the Doxygen reference with whatever > > other > documentation you have > > http://www.doxygen.nl/manual/autolink.html suggests that links to external URLs > are recognised by doxygen. Presumably linking to the correct place vis-a-vis > release/developer builds can be controlled with a macro in a generated Doxyfile? > > > And it's Doxygen to XML, XML to Boostbook. Then of course Boostbook to > Docbook, and Docbook to HTML. > > Other than the very pleasing boost documentation styling, is this seemingly > convoluted conversion route necessary? Is it not possible to configure a Doxyfile to > contain the correct styling? > > I have no knowledge of the evolution of boost documentation and have no axe to > grind, but as a newcomer it seems to me that there is a lot of 'unnecessary' > compication in the production of documentation. I appreaciate that there's no real > sense in revisting existing libraries, but for new ones wouldn't it be prudent to > choose the shortest possible path which involves the least learning and > maintenance? It depends on the size of the documentation. For 'trivial' documentation, the Doxygen and Markdown combination is acceptable, but I believe strongly that the best Boost documentation is done using the Quickbook toolchain (including Doxygen syntax comments to provide a references section). A killer feature of Quickbook is the ability to include code snippets from actual C++ examples that can be run, ensuring that what you get is what compiles and runs. As a mark-up language Quickbook is pretty obvious (apart from the gotcha of using indent-spaces as a way to add code sections - a common but quick'n'dirty markup feature that can cause some confusion). Paul

1 0

Boost ASIO
by live man 03 Jan '20

03 Jan '20

Hi, We have been using Boost for our firmware product which runs in ARM processor. However for development we make use of Visual Studio IDE. We also have our own TCP / IP suite which defines its own socket.h file. We are facing issue related to using Boost ASIO in Windows development platform. It seems that the library by default includes windows networking header files - which we do not want. Instead we want Boost ASIO to make our own library socket headers and declaration. We noticed that if we include Boost ASIO and our TCP / IP socket declaration we get re-definition error and compilation fails with lots of errors? Please let us know how we can resolve the issue with the objective mentioned above? Thanks in advance. Regards, Prakash

2 2

Google Summer of Codes 2020
by saloni garg 02 Jan '20

02 Jan '20

Hello, My name is Saloni Garg. I am an undergraduate student of B.tech in computer engineering. Currently, I am in my second year and I am looking forward to participate in this year's Google Summer of code 2020. So, I want to know, if Boost organization is planning to be a part of this year's Google Summer of codes 2020? Thank you! Saloni Garg

1 0

Recomended way of generating documentation
by Alexander Grund 01 Jan '20

01 Jan '20

Hi, I'm currently in the process of generating documentation in a Boost usable format and got a couple questions. The documentation is currently in-source in Doxygen format and has a markdown file for the start page. 1. Which aliases do I need and for what? I've seen boostdoc and boostrelease but couldn't find a description what and why they are 2. Where do the documentation files need to go? It seems using BJam naively outputs them to bin.v2 not to the libraries doc folder which I'd even see useful because generated files should not clobber the source tree 3. What benefit is there going from Doxygen (over multiple conversions) to boostbook? Can't I just go from Doxygen to HTML? 4. If the above: Calling `doxygen mylib.html` in BJam generates a mylib folder and a mylib.html redirecting into that folder. Both hardcoded to go into a subfolder of bin.v2. How is that useful/useable? Wouldn't I want a 'html' folder and an index.html redirecting to the index.html contained or no redirection file at all? 5. As I'm thinking about calling doxygen manually: Do I need to do anything so e.g. mylib shows up in boost/doc/html? Why is only a subset of the libraries there? Thanks for any help or pointers! Alexander Grund

6 5

Boost-GIL GSOC 2020
by Siddhartha Sen 31 Dec '19

31 Dec '19

Hello, I would like to propose an idea for GSOC 2020. I would like to re-implement pre existing features in Boost-GIL for example inverting an image, conversion from black and white to colour and vice versa, etc, but with the usage of parallel programming in order to improve the efficiency and speed things up. This is nothing but an idea merely, as I have some idea with parallel programming beforehand. Could anyone give me some guidance as in how to proceed with this? And also do you all think this is a good enough proposal? I already have built a couple of libraries for image conversion using openmp, but I am not sure whether they are boost compatible or not. Thank You.

2 1

Re: [boost] [review] [STLInterfaces] STLInterfaces review starts today
by Andreas Wass 28 Dec '19

28 Dec '19

This my small review of STLInterfaces, and mainly iterator_interface > - Your name Andreas Wass > - Your knowledge of the problem domain I implement mainly iterators every once in a while, both at work and for personal projects. I have mainly used iterator_interface but used container_interface as well. > - Whether you believe the library should be accepted into Boost (be clear > about this) Yes, it helps cutting down on the amount of boilerplate to write. > In addition, you are strongly encouraged to answer the following questions: > - What is your evaluation of the library's > * Design? The design seems solid > * Implementation? Looks solid as well, only had one issue with container_interface (see below). > * Documentation? It is ok. As someone who isn't implementing containers all that often it would be nice to have signatures as well as expressions listed in the container_interface documentation > - Did you attempt to use the library? If so: > * Which compiler(s)? MSVC 2017 and GCC 9 > * What was the experience? Any problems? One problem with container_interface. See https://github.com/tzlaine/stl_interfaces/issues/12 > - How much effort did you put into your evaluation of the review? About two hours implementing iterators and a container

4 5

[review][STLInterfaces] STLInterfaces review results
by Barrett Adair 26 Dec '19

26 Dec '19

Many thanks are owed to all who participated in the formal review of Zach Laine's STLInterfaces library, especially during this busy holiday season: * Hadriel Kaplan - ACCEPT * Andreas Wass - ACCEPT * Rainer Deyke - ACCEPT * Arthur Gruzauskas - ACCEPT * Krystian Stasiowski - ACCEPT * Daniela Engert - CONDITIONALLY ACCEPT * Gavin Lambert - Technical comments First, a summary of the reviews: 1. Design Reviewers were unanimous in their appreciation for the design. Krystian had the only asterisk about the design, noting that derived class members should ideally be SFINAE-detected, where the library feature would SFINAE where the corresponding required derived feature detection fails. I have a different opinion about this, but we can discuss that elsewhere. 2. Implementation The container_interface destructor and the optional dependency on cmcstl2 were snags for multiple reviewers. Several compile errors were discovered that need to be addressed. 3. Documentation Reviewers found the documentation to be "ok". A common request was for better organization of derived-class requirements, particularly with the container_interface template. Reviewers also lamented the lack of training wheels for the subject matter. 4. Tests Hadriel noted the lack of non-copyable value_type tests, while Daniela noted the lack of Boost.Build support. Hadriel was the only one who commented on the quality of tests ("good"), and the only one who ran them. Arthur did his own testing, to satisfaction. I appreciate the presence of SFINAE-friendliness tests and the continuous integration. 5. Usefulness Reviewers appreciated the usefulness of the library. Arthur is "using it happily", while others found it "very useful", "fairly useful", or of "high" usefulness. However, Krystian's response implied that this library may not be as useful for containers needing extreme performance. The reviews clearly demonstrate a consensus. Accordingly, I'm pleased to announce that STLInterfaces is CONDITIONALLY ACCEPTED as a Boost library. Conditions for acceptance: 1. Remove optional dependency on cmcstl2 (issue #27) 2. Add Boost license comments to all files, including appveyor.yml, .travis.yml, README.md, */CMakeLists.txt (issue #26) 3. Support Boost.Build (issue #25) 4. Replace googletest with Boost equivalent (issue #24) 5. Remove usage of non-existent v2_dtl members in container_interface.hpp (issue #22) 6. Include <tuple> for std::tie usage in C++14 mode (issue #21) 7. Fix dangling parens in container_inteface.hpp:731 (issue #20) 8. Make Concepts usage C++20-conformant (issue #13) 9. Remove the destructor in container_interface (issue #12) 10. Add tests for non-copyable value types (issue #30) Suggestions: 1. Explicitly document the signatures and return types of functions provided by base class templates (issue #23) 2. Mention the C++20 generator pattern in documentation (issue #19) 3. Document the library's interactions with Ranges (issue #18) 4. Remove unnecessary comments (issue #17) 5. Investigate compile error in VS2015 (msvc 19.0.3) due to issues with noexcept() operator in function overloading (issue #16) 6. Rename container_interface to sequence_container_interface (issue #15) 7. Change the 'contiguous' bool to an enum (issue #14) 8. Document the relationship between value_type operator== and containter_interface-defined operator== (issue #11) 9. Improve table/section names for better navigation of container_interface tutorial (issue #10) 10. Clean up BOOST_STL_INTERFACES_DOXYGEN usage (issue #28) 11. Split up fwd.hpp into multiple headers (issue #29) 12. Document optimization trade-offs of proxy_iterator_interface (issue #30) Rationale: 1. Condition #1 is, I feel, the appropriate default as review manager. If Zach feels strongly about keeping the optional dependency on cmcstl2, we should discuss. 2. Unless the library requirements webpage has fallen out of date, new libraries must still support Boost.Build. 3. A not-so-quick grep of current Boost libraries yields no `gtest` results. I assume that we do not allow googletest as the sole test framework in a library. 4. The other conditions should be self-explanatory. Thank you Zach for your contributions, and I look forward to working with you to add this library into Boost. Regards, Barrett Adair

2 2

[review] [STLInterfaces] STLInterfaces review starts today
by Barrett Adair 26 Dec '19

26 Dec '19

Dear Boost, The formal review of Zach Laine's STLInterfaces library begins now, and will run through December 19. Please participate in this review if you can. To submit a review, please reply to this email with the following information: - Your name - Your knowledge of the problem domain - Whether you believe the library should be accepted into Boost (be clear about this) In addition, you are strongly encouraged to answer the following questions: - What is your evaluation of the library's * Design? * Implementation? * Documentation? * Tests? * Usefulness? - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? STLInterfaces is a C++14 library targeting ISO standardization. The following templates are provided, all C++20-friendly: 1. iterator_interface - a modern version of the iterator_facade and iterator_adaptor parts of Boost.Iterator 2. view_interface - a pre-C++20 implementation of C++20's eponymous feature 3. container_interface - a tool to eliminate boilerplate when writing new containers We would appreciate answers to these library-specific questions: - Do you like the name container_interface? sequence_container_interface is more precise, but seems a bit long. - Would you use something like container_interface, but for associative containers? If so, should it assume a node-based interface, a la std::map and std::set? This assumption would preclude alternative associative container-like types, such as flat_map. Code: https://github.com/tzlaine/stl_interfaces Docs: https://tzlaine.github.io/stl_interfaces/doc/html/index.html Thanks, Barrett

9 15

Re: [boost] [config][build] Doc missing in 1.72
by Glen Fernandes 25 Dec '19

25 Dec '19

On 2019-12-24 Glen Fernandes wrote: > Yes. config.htm was a file in boostorg/config until recently. > > Now that it has been removed, meta/libraries.json's documentation > entry needs to be updated: > https://github.com/boostorg/config/blob/develop/meta/libraries.json#L5 > > From "config.htm" to "doc/html/index.html". > > Glen Fixed on develop: https://www.boost.org/doc/libs/develop/libs/libraries.htm (The Config link now goes to the Config documentation). Glen

4 4

Merry Christmas All...
by Ggh 25 Dec '19

25 Dec '19

Hi, Merry christmas to all of you. Happy holidays Cheers Greg Tell me, and I forget. Ask me, and I discover...

1 0

Re: [boost] Proposed legacy macro renaming policy
by Glen Fernandes 25 Dec '19

25 Dec '19

On 2019-12-19 Niall Douglas wrote: > On 18/12/2019 13:51, Glen Fernandes wrote: >> I've fixed the macros in: >> * boostorg/multi_array >> * boostorg/iterator >> * boostorg/parameter >> * boostorg/polygon > > Thanks! > > I reckon with the above about two thirds of the libraries listed at > https://github.com/boostorg/boost/issues/352 are fixed now. > > Niall In addition to the four above, I've now also fixed: * boostorg/bimap * boostorg/lambda * boostorg/graph * boostorg/property_map The rest of the libraries have active maintainers so they should be able to take care of them.

1 0

(no subject)
by Glen Fernandes 25 Dec '19

25 Dec '19

On 2019-12-19 Niall Douglas wrote: > On 18/12/2019 13:51, Glen Fernandes wrote: >> I've fixed the macros in: >> * boostorg/multi_array >> * boostorg/iterator >> * boostorg/parameter >> * boostorg/polygon > > Thanks! > > I reckon with the above about two thirds of the libraries listed at > https://github.com/boostorg/boost/issues/352 are fixed now. > > Niall In addition to the four above, I've now also fixed: * boostorg/bimap * boostorg/lambda * boostorg/graph * boostorg/property_map The rest of the libraries have active maintainers so they should be able to take care of them. Glen

1 0

[config][build] Doc missing in 1.72
by Edward Diener 24 Dec '19

24 Dec '19

In the 1.72 distribution the documentation for config and build are missing.

3 5

[review][fixed_string] FixedString review results
by Joaquin M López Muñoz 22 Dec '19

22 Dec '19

These are the results of the candidate Boost.FixedString review. Thanks to all the people (and there's been many) who contributed. To clear up the tension, let me begin by announcing that: Candidate Boost.FixedString is ACCEPTED into Boost. Acceptance is subject to the authors' addressing of some issues raised during the review that I label as "priority 1" below. *Summary of reviews* We've had 10 full reviews: * Accept: Deniz Bahadir, Emil Dotchevski, Gavin Lambert, JeanHeyd Meneide, Paul A. Bristow, Peter Dimov, Peter Koch Larsen. * Conditionally accept: Zach Laine. * Reject: Andrzej Krzemienski, Phil Endecott. Zach's conditions to acceptance seem minor and easily addressable to me. Andrzej based his rejection on a perceived lack of clarity as to what the actual pitch of the library is, which ultimately boils down to the issue of throwing/asserting on capacity overflow: my impression is that a strong pitch, if not a universally acclaimed one, emerged during discussions. Finally, Phil voted to reject but then went on to state that he would accept based on a number of "minimally sufficient" conditions that are trivial to meet (or even have been already implemented by Krystian). All in all, I think it is a reasonable compromise to grant acceptance based on the resolution of a number of important issues, listed below. *Issues* I've classified issues in three different priorities: * Priority 1: to be solved *before* inclusion into Boost. * Priority 2: to be addressed somewhere in the future. * Priority 3: anecdotal or without clear support from the community, to be addressed at the authors's discretion. * Priority 1 issues* 1. CMakeLists.txt should either be made generic or removed from repo (it is currently a specific thing for Visual Studio). 2. Choose a name for the component. Some consensus arose that naming should follow std::string's and be of the form basic_foo<...> with aliases foo, wfoo, etc. As for "foo", the following candidates have been proposed: * static_string * fixed_capacity_string * array_string * static_capacity_string * inplace_string * capped_string * bounded_capacity_string * bounded_string To be clear, I don't think any of these is clearly more popular than the rest, so it is up to the authors to make up their mind. 3. constexpr as much as possible, taking into account that, pre C++20, this requires zero initialization of the data array. 4. noexcept as much as possible and, in principle, at least as much as std::string. 5. Provide hash overloads. Up to the authors if they want to cover Boost.Hash as well. 6. Determine the exact behavior on capacity overflow. I think *some* partial consensus arose around throwing via boost::throw_exception so as to provide an opt-out mechanism for exception-handicapped scenarios. This has been the most contentious issue during the review but I think the authors are in their right to decide on throwing much as anyone can decide otherwise and propose what would be basically a different library. 7. Make substr return a fixed_string rather than a view, and additionally provide a view-returning subview member function. 8. State clearly on the docs what C++ version is required. 9 There are wrong "size() + m > max_size()" checks (they could overflow) in the code. 10. to_fixed_string should be a set of overloads mathing those of std::string. 11. There's an issue around some detail::is_input_iterator alias that Zach asked be clarified. 12. Compile-fail tests should be added to verify that those functions with constraints are correctly constrained. *Priority 2* 13. Determine if fixed_string<0> should be specialized or not to make it more memory efficient. This raises potential issues in the uniqueness of the pointer returned by data(). 14. Determine if operator+(fixed_string,fixed_string) should be provided. My impression is that people generally wanted this, and I've been tempted to raise this to priority 1. 15. Optimize the type of the internal size data member when size_t is larger than necessary. 16. BOOST_FIXED_STRING_USE_BOOST is unconditionally defined within the code. The authors should clearly state what this is for and let the user configure the library to use with/without Boost or, else, remove the thing entirely. 17. Source code organization (three equally named files, detal and impl folders), raised some eyebrows. Some (including Vinnie) favor a single-file implementation. 18. Docs should be more C++ standard-like and provide a synopsis. Vinnie has indicated they may abandon Doxygen in favor of asciidoc to produce better-quality docs. In general, people were not enthusiastic about the documentation. 19. The current monolithic test should be split up in lighter, more manegeable test files. Peter Dimov suggested some additional improvements on the testing part. * Priority 3* 20. Provide a literal operator"" 21. Should traits parameter be removed? 22. Store size (as capacity-size) in the last char of the data array, so as to save one memory byte. This might affect performance, though. 23. Add functions for checking remaining capacity. Thanks to Krystian and Vinnie for their work! And to everybody who has contributed to this really interesting review. Best regards, Joaquín M López Muñoz Review manager for candidate Boost.FixedString

7 12

[gsoc2020] New here
by Siddhant Jain 22 Dec '19

22 Dec '19

Hi, my name is Siddhant I am a first year CS student at IIIT Hyderabad. I am interested in learning more about and contributing to boost. I have visited the obvious beginners links but I am unable to grasp the library to the level where I can contribute code. What would be the suggest plan of action to get comfortable with reading and write code used in boost. I am interested in working on Boost.geometry and/or Boost.real. Thanks

1 0

[move][core] boost::swap() vs boost::adl_move_swap()
by Andrzej Krzemienski 21 Dec '19

21 Dec '19

Hi Everyone, I am seeking an advice. I recently got this pull request: https://github.com/boostorg/optional/pull/77 changing the boost::swap() to boost::adl_move_swap() because it should compile faster. Is there any recommendation for Boost libraries which one to prefer and under what circumstances? boost::adl_move_swap() seems to allow moves rather than copies in more cases. On the other hand boost::swap() seems to have other improvements, like BOOST_GPU_ENABLED. Regards, &rzej;

2 1

boost::python::def_visitor alignment / padding crash.
by Janek Kozicki 20 Dec '19

20 Dec '19

I have discovered an alignment related bug in boost::python::def_visitor For a very detailed description see https://gitlab.com/libeigen/eigen/issues/1795 * a minimal failing example: https://gitlab.com/cosurgi/minieigen-real/blob/minimalFailingExample/src/mi… * and the failing CI pipeline: https://gitlab.com/cosurgi/minieigen-real/pipelines/104745741 Initially I thought that it was related with libeigen. But it turns out that it crashes even without libeigen, when just using boost::multiprecision::float128. The code crashes with g++ 8.3.0 and works with g++ 9.2.1 boost version 1.67 is used there. should I open an issue on boost github? best regards -- # Janek Kozicki http://janek.kozicki.pl/

1 1

[appveyor] Really slow turnover
by Edward Diener 20 Dec '19

20 Dec '19

When I started out in computer programming some 40 years ago you could submit a job, with some JCL, on an IBM mainframe computer via an input card reader and you were lucky if you got back the result a day later. How happy I was when I went to microcomputers and could get almost instantaneous results from any programming attempt. Fast forward to now, some 40 years later, and it seems like nothing changes, despite the great advancement in computer technology and online access in our current age. Attempting to run CI using Appveyor literally has jobs queued pending a run for days and days. Surely there must be something better in this day and age than this ridiculously slow internet service. Is it 1979 again ?

7 18

[review][STLInterfaces] review extended to Dec. 23
by Barrett Adair 20 Dec '19

20 Dec '19

The formal review of STLInterfaces is extended to December 23. Please consider submitting a review if you can.

1 0

Re: [boost] Jason is getting MARRIED!
by Bjorn Reese 20 Dec '19

20 Dec '19

On 11/16/19 7:09 PM, Vinnie Falco via Boost wrote: > My JSON library is going to propose to Boost soon, is there anyone who > might be willing and able to function in the role of review manager? Before we get to that point, there are some questions that the community should address. These days there are a huge number of JSON libraries out there. Some focus on features (e.g. binary JSON or JSONPath), others on performance, and others on user-friendliness. What competitive edge should a potential Boost JSON library offer? Which use cases should a potential Boost JSON library support? Should the library work seemlessly with standard algorithms? Should it be possible to create parser combinators? Should there be a JSON archive for Boost.Serialization? Should it replace parts of Boost.PropertyTree? PS: On a procedural note, you need an endorsement of the library before seeking a review manager.

10 68

GSoc 2020
by Aniswar SK 19 Dec '19

19 Dec '19

Hello everyone, I am Aniswar Krishnan, a 2nd year Computer Science student at Indian Institute of Technology, Madras. I am have been coding in c++ and python for the past 15 months. I am interested in Mathematics and Algorithms and have done courses on same along with Data Structures, Linear Algebra. I got interested int the projects like Boost.Real and Boost GIL and would like to contribute more to the community. Please guide me and share the relevant resources needed. Will be grateful. Regards, Aniswar Krishnan II Year Computer Science IIT Madras Chennai, Tamil Nadu

3 2

Re: [boost] Proposed legacy macro renaming policy
by Glen Fernandes 18 Dec '19

18 Dec '19

I've fixed the macros in: * boostorg/multi_array * boostorg/iterator * boostorg/parameter * boostorg/polygon Glen

2 1

What to do about Boost libraries which use user-defined macros which are not BOOST_ prefixed
by Niall Douglas 18 Dec '19

18 Dec '19

Acting on guidance given to my recent supply to this list of unprefixed macros, namespaces etc injected into the global namespace by Boost, I have logged a list of all issues with each library, and linked to all those from a single issue logged at https://github.com/boostorg/boost/issues/352. A problem has arisen which requires input from boost-dev. Some Boost libraries define as part of their public API a non-BOOST_-prefixed macro which changes the definition of their header files e.g. PHOENIX_LIMIT (just to be clear, Phoenix is not the only library doing this) If we change such macros to be like BOOST_PHOENIX_LIMIT instead, all existing code using Boost which sets PHOENIX_LIMIT would potentially *silently* break. What we could decide to do instead is: #if defined(PHOENIX_LIMIT) && !defined(BOOST_PHOENIX_LIMIT) #error In Boost 1.xx PHOENIX_LIMIT was renamed to BOOST_PHOENIX_LIMIT. Please upgrade your code to reflect the new name. #endif Or one could just leave PHOENIX_LIMIT named as is. What would Boost developers prefer we do? Niall

8 19

Re: [boost] [review] [STLInterfaces] STLInterfaces review starts today
by Hadriel Kaplan 18 Dec '19

18 Dec '19

Howdy, For this review I've really only tried out the iterator_interface part. I'm sorry I can't provide feedback on the container_interface nor view_interface, as I just don't have the free cycles. > - Your name Hadriel Kaplan > - Your knowledge of the problem domain I've been using boost's iterator_facade and adaptor for a long time; I've written my own custom iterators as well, of both traditional and proxy-types. The usual stuff. > - Whether you believe the library should be accepted into Boost (be clear about this) Definitely. It could use word-smithing and minor cleanup stuff, but presumably that happens later. (?) > - What is your evaluation of the library's > * Design? Good overall. > * Implementation? Good. I've got some nitpicks, but honestly none are a big deal. minor nitpicks: 1) I didn't use the proxy_iterator_interface one, only looked at the code. The proxy_arrow_result storing a local T value that it only returns a pointer to, means it's not optimal in some cases. Obviously for something like std::vector<bool> it won't matter, but some value-types are not so lightweight. On the other hand, it looks like we can specialize this for our type (or not even use proxy_arrow_result to begin with)? 2) Can the stuff in fwd.hpp be split out? I could be wrong, but I don't think most of it is needed/used by iterator_interface, and only used by the other two, correct? Reducing what gets included would be nice, for people who don't need the container/view stuff. The old boost iterator_facade/adaptor headers included so much that it drove some people to stop using them; for example see the comments here: https://github.com/facebook/folly/blob/master/folly/detail/Iterators.h 3) This lib hasn't been tested for C++20, and obviously can't be yet, but it makes assumptions that it can safely replace some of its internals with C++20's new ones. Things like concepts and ranges. I'm not sure that's advisable, until all the major compilers support them and can be tested. It would be a shame if people using this lib can't upgrade to C++20 because it breaks this lib, until they upgrade boost as well. (not a big deal, just more noting it) 4) The files use a macro to control doxygen output. Is this still required for boost libs? Doxygen has had the cond/endcond commands for a long, long time. It's kinda ugly to see these macros, and kinda silly that everyone's compiler will be evaluating them all the time. (I know that's super-nitpicky) 5) I assume all the _has_include(<stl2/ranges.hpp>) checks will be removed, since that's a thirdparty header? 6) This lib requires C++14, but I don't see a macro checking that anywhere and providing a simple error to the user. 7) I can't decide if the BOOST_STL_INTERFACES_STATIC_ASSERT_ITERATOR_TRAITS() thing is a good idea or a waste of time. I tried it, it passed. But of course it did, because it's just checking that I got the API that I told iterator_interface to create, no? This just seems like needless repetition to me. I mean if I screwed it up to begin with, I'll screw it up in this macro too, no? But maybe I'm missing something obvious. (could be - it's getting late) > * Documentation? It's OK. I enjoyed some of the humor. :) It's missing some info for things that are customization points. For example base_reference() is shown in an example, but not really documented anywhere as far as I can tell. The tables aren't as useful/explanatory as one would hope. I mean I knew what they meant, but I'm not sure someone newer to this area would. (but then again, that's what blogs/articles are for I guess) I think it might also help if there were some explanation for what happens under-the-hood, in terms of what public methods get auto-generated from what, for which iterator types. For example, it's surprising that for a bidirectional iterator the user defines operator==(), but not for random-access iterator. (that particular case happens to be mentioned in a note, but you get my point) There are also typos and such, but I presume that gets checked later. > * Tests? Good. I copied them over and ran them as well. (but not the v2 tests, nor the ones for container_interface or view_interface) I think it would be better if there were some tests for iterator_interface with non-copyable value-types. Testing it only for `int`s is cheating. :) Also, random question: for the container_interface, did you try using it with the boost::fixed_string (or static_string, or whatever it's called)? I mean that _is_ a contiguous container, and it's in boost review too, so might it be a good test candidate? :) > * Usefulness? Very useful. iterator_facade/adaptor were showing their age. It's time for something new and shiny. I was happy that it reduced the number of functions we needed to implement in our current usages from 5 to 3. > - Did you attempt to use the library? Yup. I replaced three existing boost::iterator_facade usages in my company's code-base with this one, to try it out. Ran our unit tests with and without valgrind as well. But to be honest these weren't very complicated iterators. I did _not_ try replacing boost::iterator_adaptor, but I hope to try that eventually. > * Which compiler(s)? (old ones, so I could build my employer's codebase and run all their unit tests...) 1) gcc 7.3.1 with c++17 2) clang 5.0.0 with C++17, using gcc's libstdc++ Both using boost 1.55 (sorry!), with the stl_interfaces headers copied over manually, without using the CMake files in the github repo. Neither compiler has the early Concepts support. > * What was the experience? Any problems? Not really. The hardest part was figuring out the new model of what the derived had to define, compared to iterator_facade. (i.e., I was so used to the old model that it took me a bit to grok this one) > - How much effort did you put into your evaluation of the review? Only a few hours, maybe 4-5 total. Sorry, I wish I had more free time. :( > - Do you like the name container_interface? sequence_container_interface > is more precise, but seems a bit long. I'm not sure the length matters much for this use-case, as it's a one-time thing (generally), and not used by users of the actual container; and can anyway be aliased. (I mean, the "stl_interfaces" sub-namespace is annoying too, but it's not a big deal in my opinion) > - Would you use something like container_interface, but for associative > containers? If so, should it assume a node-based interface, a la std::map > and std::set? This assumption would preclude alternative associative > container-like types, such as flat_map. Yes I think so, depending on what it did... but for *unordered* ones (i.e., hash-maps/sets), rather than rb-trees. I often find myself encapsulating them, and then having to write a lot of boilerplate public member functions. And several functions can be boiled down for hash-maps. For example count() and contains() can just use find(). I don't know why an unordered_container_interface wouldn't be do-able, including heterogenous lookups, for various hash-map/set flavors. (except, of course, that boost::unordered_map/set's API is different than std's for heterogeneous lookup; which is unfortunate) -hadriel

1 0

[review] [STLInterfaces] STLInterfaces iterator_interface mini mini review
by Arthur Gruzauskas 18 Dec '19

18 Dec '19

On Wednesday, 11 December 2019 11:21:23 AM AEDT Barrett Adair via Boost wrote: > Dear Boost, > > The formal review of Zach Laine's STLInterfaces library begins now, and > will run through December 19. Please participate in this review if you can. > To submit a review, please reply to this email with the following > information: > - Your name Arthur Gruzauskas > - Your knowledge of the problem domain I've written a number of iterator interfaces over the years. Nothing fancy, but have dipped my toes in iterator implementation. > - Whether you believe the library should be accepted into Boost (be clear > about this) ACCEPT, simply because I am using it happily. but I have only used container_interface, not the rest. > > In addition, you are strongly encouraged to answer the following questions: > - What is your evaluation of the library's > * Design? simple interface, small learning curve, great value for effort. A small number of methods to implement the essential concepts. A small enough concept chunk to be easily manageable. simple to use, just copied the code in the readme.md and adapted it. > * Implementation? worked for me. I didn't examine the code much. I like its layout and it looks clean to me. > * Documentation? The readme.md with that simple example was enough for me to adapt the intro sample iterator to my code. I note the example has been criticised by Gavin Lambert a few posts ago. But I love it as it made everything simple and clear. Reading the main doc page filled in a few conceptual gaps, but that readme.md gave me the overview that made the rest easy. > * Tests? So far brief tests have all worked well. I did not exhaustively test the iterators. They also worked fine in a couple STL algorithms. Again, I have only dealt with iterator_interface.hpp > * Usefulness? My experimental class would have stalled for some time if this easy iterator interface had not been there. Encouraged, I'm now looking at using it for more complicated structures. > - Did you attempt to use the library? If so: > * Which compiler(s)? clang-8 for c++17 on debian linux. > * What was the experience? Any problems? very straightforward. a few small glitches, as I just grabbed iterator_interface.hpp and fwd.hpp and made small changes for it to work inside my project. https://github.com/tzlaine/stl_interfaces/issues describes two minor issues, which could be well related to me just grabbing those 2 files only, outside the boost structure that would normally sustain it. > - How much effort did you put into your evaluation of the review? Several hours reading, adapting and getting it working for me. > > STLInterfaces is a C++14 library targeting ISO standardization. The > following templates are provided, all C++20-friendly: > > 1. iterator_interface - a modern version of the iterator_facade and > iterator_adaptor parts of Boost.Iterator > 2. view_interface - a pre-C++20 implementation of C++20's eponymous feature > 3. container_interface - a tool to eliminate boilerplate when writing new > containers > > We would appreciate answers to these library-specific questions: > - Do you like the name container_interface? sequence_container_interface > is more precise, but seems a bit long. It doesn't clash with anything in my mental namespace, so I'm happy with the name container_interface. BTW, I have not used container_interface, I just saw it now and had a look. I can see this simplifying some upcoming containers, and will certainly be giving it a go. view_interface is not something I have a need for currently. > - Would you use something like container_interface, but for associative > containers? > If so, should it assume a node-based interface, a la std::map > and std::set? This assumption would preclude alternative associative > container-like types, such as flat_map. > > Code: https://github.com/tzlaine/stl_interfaces > Docs: https://tzlaine.github.io/stl_interfaces/doc/html/index.html > > Thanks, > Barrett > My one small concern is in the required method: constexpr auto operator-(repeated_chars_iterator other) const noexcept instead of: constexpr auto operator-(const repeated_chars_iterator& other) const noexcept I may soon have a need for an iterator that holds a lot of state, and copying that iterator for each subtraction makes me wonder about a performance penalty in inner loops. It is not a dealbreaker for this review, and I didn't examine Zach's tradeoffs for doing it this way. I see many of my use cases where this approach will be fine. This is my first review, incomplete as it is, mainly motivated because no one else has done one yet, and because I found iterator_interface useful and want to encourage Zach for this lovely simplifying interface. Thanks very much, Zach. Arthur

3 4

Unmerged change in boostcpp.jam
by Peter Dimov 17 Dec '19

17 Dec '19

boostcpp.jam on develop contains the following patch, which is not merged to master: diff --git a/boostcpp.jam b/boostcpp.jam index efc41c1ed..299401778 100644 --- a/boostcpp.jam +++ b/boostcpp.jam @@ -607,7 +607,7 @@ rule address-model ( ) return <conditional>@boostcpp.deduce-address-model ; } -local deducable-architectures = arm mips1 power sparc x86 combined ; +local deducable-architectures = arm mips1 power riscv s390x sparc x86 combined ; feature.feature deduced-architecture : $(deducable-architectures) : propagated optional composite hidden ; for a in $(deducable-architectures) { @@ -618,11 +618,13 @@ rule deduce-architecture ( properties * ) { local result ; local filtered = [ toolset-properties $(properties) ] ; - local names = arm mips1 power sparc x86 combined ; + local names = arm mips1 power riscv s390x sparc x86 combined ; local idx = [ configure.find-builds "default architecture" : $(filtered) : /boost/architecture//arm : /boost/architecture//mips1 : /boost/architecture//power + : /boost/architecture//riscv + : /boost/architecture//s390x : /boost/architecture//sparc : /boost/architecture//x86 : /boost/architecture//combined ] ; This seems to add support for "riscv" and "s390x" as architectures. Should this be merged to master?

1 0

Test Matrix not Updating
by Michael Caisse 16 Dec '19

16 Dec '19

We are aware that the test matrix has not been updating. The problem is caused by a server that we do not control. Things should be resolved in the next couple days. Thank you for your patience and sorry about the disruption. michael -- Michael Caisse Ciere Consulting ciere.com

1 0

Enabling warnings for library sources and tests but not for dependencies
by Alexander Grund 15 Dec '19

15 Dec '19

Hi, I want to build at least the tests but better also the library sources itself with warnings enabled and warnings-as-errors to avoid regressions. >From BoostAssert I found the following snipped added to the top of test/Jamfile.v2: project : requirements <warnings>pedantic <warnings-as-errors>on ; Further down I have a dependency on BoostFilesystem like: run test_stdio.cpp : : : <library>/boost/filesystem//boost_filesystem ; But now the build of BoostFilesystem fails: gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-5.4.0/release/cxxstd-11-iso/threading-multi/visibility-hidden/directory.o libs/filesystem/src/directory.cpp:217:48: error: unused parameter 'buffer' [-Werror=unused-parameter] Is there any way to restrict the warnings to my project only? Or at least the warnings-as-errors option? Is there a way to set warnings-as-errors via b2 command only for this library? This would avoid putting it in the Jamfile which could affect end-users, but having it on CI is actually enough. Alex

2 3

bug-fix release 1.72.1?
by Oliver Kowalke 15 Dec '19

15 Dec '19

Hello, unfortunately I accepted a faulty pull request and the commit that reverted it was not included into release 1.72 (for instance spawn() of Boost.Asio will fail to compile). Oliver

3 4

Assuming maintainership of boostorg/io
by Glen Fernandes 15 Dec '19

15 Dec '19

I'd like to take on maintainership of IO, as suggested by Peter. So far, I've already: * Implemented the Fundamentals TS v2 ostream_joiner as boost::io::ostream_joiner * Converted the documentation to Asciidoc * Updated the test cases to use Lightweight Test and build faster * Updated the CI configurations I also plan to: * Finish the boost::io::quoted implementation started by Beman but currently in detail. i.e. Update and improve the implementation. Add better documentation and more tests, and make it non-detail (public). * Migrate my boost::ostream_string facility from Boost.Utility (which is more general purpose) to Boost.IO (because, well, IO). * Make some minor improvements to the implementation of boost::io::ios_state. Glen

2 1

Re: [boost] Assuming maintainership of boostorg/io
by Bjorn Reese 14 Dec '19

14 Dec '19

On 2019-12-14 17:31, Glen Fernandes via Boost wrote: > I'd like to take on maintainership of IO, as suggested by Peter. +1

1 0

Attn: Maintainer of boost/bind.hpp
by Niall Douglas 13 Dec '19

13 Dec '19

In boost/bind.hpp there is injection of a boost namespace contents into the global namespace: ```c++ #include <boost/bind/bind.hpp> #ifndef BOOST_BIND_NO_PLACEHOLDERS #if defined(BOOST_CLANG) # pragma clang diagnostic push # if __has_warning("-Wheader-hygiene") # pragma clang diagnostic ignored "-Wheader-hygiene" # endif #endif using namespace boost::placeholders; #if defined(BOOST_CLANG) # pragma clang diagnostic pop #endif #endif // #ifndef BOOST_BIND_NO_PLACEHOLDERS ``` The fact that Boost actually disables the relevant compiler warning makes this particularly insidious. No modern C++ library should ever do "using namespace" into the global namespace in its public headers. Please fix this in the next release of Boost. Niall

2 4

Attn: Maintainers of Iterator, Python, ASIO, Detail, Core, Graph, QVM, Exception
by Niall Douglas 13 Dec '19

13 Dec '19

Dear maintainers of Iterator, Python, ASIO, Detail, Core, Graph, QVM, Exception, Please find attached a list of macros in your libraries without BOOST_ prefixing, as is required by Boost library guidelines. If you could fix these promptly, it would be appreciated. Niall

1 1

Re: [boost] [release] Boost 1.72.0 has been released
by Glen Fernandes 12 Dec '19

12 Dec '19

Andrey wrote: > In release notes, New Libraries says TODO. Also on the main page it showed a blank list of updated libraries. Both should be fixed now: https://github.com/boostorg/website/commit/3f37b654d7126c0ad312e50d227c03d2… https://github.com/boostorg/website/commit/7c897e8c768cf28113ba07488a6b5030… Glen

2 1

[release] 1.73.0 open for merging
by Marshall Clow 11 Dec '19

11 Dec '19

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: https://github.com/boostorg/boost/wiki/Release-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

1 0

[release] Boost 1.72.0 has been released
by Marshall Clow 11 Dec '19

11 Dec '19

Release 1.72.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains new libraries and numerous enhancements and bug fixes for existing libraries. For details, including download links, see < http://www.boost.org/users/news/version_1.72.0> You can also download directly from: < https://dl.bintray.com/boostorg/release/1.72.0/> To install this release on your system, see < http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Marshall Clow, Michael Caisse

3 2

[release] Boost 1.72.0 Release Candidate 2
by Marshall Clow 10 Dec '19

10 Dec '19

The second release candidates for the 1.72.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.72.0/source/> The SHA256 checksums are as follows: 247a91dd7e4d9dd3c4b954b532fbc167ba62dc15ab834e5ad893d7c3f9eb5f0f ./boost_1_72_0_rc2.7z 59c9b274bc451cf91a9ba1dd2c7fdcaf5d60b1b3aa83f2c9fa143417cc660722 ./boost_1_72_0_rc2.tar.bz2 c66e88d5786f2ca4dbebb14e06b566fb642a1a6947ad8cc9091f9f445134143f ./boost_1_72_0_rc2.tar.gz 8c20440aaba21dd963c0f7149517445f50c62ce4eb689df2b5544cc89e6e621e ./boost_1_72_0_rc2.zip Changes since RC1: * A change to Boost.Proto that would cause compilation failures on the latest MS compiler. 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 Boost Release Managers

2 4

Interest in a C++20 Unit Testing Framework?
by Krzysztof Jusiak 10 Dec '19

10 Dec '19

Hi, I was wondering whether there is any interest in exploring a C++20 single header/single module, macro-free Unit Testing Framework with no dependencies? Github: https://github.com/boost-experimental/ut Additional links: - Try it online: https://godbolt.org/z/uVDxkW - Benchmarks: https://github.com/boost-experimental/ut#benchmarks - How it works?: https://github.com/boost-experimental/ut#how-it-works Thanks, Kris

8 30

Re: [boost] [STLInterfaces] only three operations?
by Zach Laine 09 Dec '19

09 Dec '19

On Mon, Dec 9, 2019 at 12:55 PM Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: > > > pon., 9 gru 2019 o 17:32 Zach Laine <whatwasthataddress(a)gmail.com> > napisał(a): > >> >> >> >>> Same with the iterator in the flight map: >>> >>> >>>> https://github.com/tzlaine/flat_map/blob/master/implementation/flat_map#L266 >>>> >>> >>> According to C++17 requirements this shouldn't have been a >>> random_access_iterator. >>> >>> Also, std::ranges::sort() will not work with it. But this is not >>> directly related to `iterator_interface` >>> >> >> I don't know why you think that. ranges::sort() is designed to work with >> std::random_access_iterator, which is designed explicitly to support proxy >> iterators. Casey and Eric have assured me that this "just works". Do you >> know of a reason why it does not? If so, you've spotted a defect, and we >> should file an LWG issue immediately. >> > > Not sure if it is a defect. An iterator that returns a proxy as > ::reference can be a valid random_access_iterator. However, > std::ranges::sort(), apart from a random_access_iterator requirement, has > one more requirement: sortable<>: (http://eel.is/c++draft/sort) which > boils down to indirectly_writable ( > http://eel.is/c++draft/iterator.concept.writable) This last concepts > puts severe restrictions on proxy types. For instance you should be able to > assign to them when they are const-qualified. So a type like std::tuple<> > of references will not work. But you will be able to design a sufficiently > bizarre proxy type that will work with std::ranges::sort(), So in a way it > will work with *some* reference proxies. > Ok, I just realized this somehow drifted off-list. Re-adding the list... This is the definition of indirectly_writable: template<class Out, class T> concept indirectly_writable = requires(Out&& o, T&& t) { *o = std::forward<T>(t); // not required to be equality-preserving *std::forward<Out>(o) = std::forward<T>(t); // not required to be equality-preserving const_cast<const iter_reference_t<Out>&&>(*o) = std::forward<T>(t); // not required to be equality-preserving const_cast<const iter_reference_t<Out>&&>(*std::forward<Out>(o)) = std::forward<T>(t); // not required to be equality-preserving }; All you need to make this work is a reference type for which all those are well-formed. If you pick std::tuple, it all just works. If you pick std::pair, only the first two expressions in the requires expression work. You can easily define UDTs for which this concept works too, of course. Zach

1 0

Interest in an audio filtering / algorithm Library?
by Vinnie Falco 09 Dec '19

09 Dec '19

Is there any interest in having a new libraries for Boost that is focused on the audio domain (but with portions applicable generically)? I'm thinking about a library that does stuff like: * finite impulse response filtering * infinite impulse response filtering * time stretching, resampling * audio synthesis * audio algorithms * mixing * plenty of ready-to-run filters: - low pass, high pass, band pass - echo, reverb, flanger, phaser and the like This is a pure math library, no actual audio. To get an idea of the algorithms and use-cases check out my DSPFiltersDemo program (press Download Now): <https://github.com/vinniefalco/DSPFiltersDemo> Please note, my library is not what is being proposed, this would be a new library from a domain expert (not me). Thanks

7 8

[review][fixed_string] review period finishes today Dec 8
by Joaquin M López Muñoz 08 Dec '19

08 Dec '19

The review period of candidate Boost.FixedString finishes today, Dec 8. Many interesting subjects have been discussed about during these two weeks and I have quite a bit of material to digest before publishing the final review result plus further action points. I expect to be able to do so during the following week. Thank you to all the people who have contributed their reviews and comments and to Krystian and Vinnie for submitting their work and enduring the famously severe review ordeal. Best regards, Joaquín M López Muñoz Review manager for candidate Boost.FixedString

2 1

Re: [boost] Boost GIL
by Siddhartha Sen 08 Dec '19

08 Dec '19

Thanks a lot for forwarding my email to the boost GIL list. I will check it out. What I meant by conversion, however was primarily converting an image to negative and greyscale. As you may already know, the two pf them are pretty similar and OpenMP has shown how incredibly fast the process can be using more threads. I just feel GIL would benefit a lot from using parallel programming. On Sun, 8 Dec, 2019, 5:30 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: [fixed_string][review] Review of fixed_string (Rob Stewart) > 2. Re: Extending GIL (Mateusz Loskot) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 07 Dec 2019 13:23:51 -0500 > From: Rob Stewart <rstewart(a)ptd.net> > To: boost(a)lists.boost.org,Phil Endecott via Boost > <boost(a)lists.boost.org> > Cc: Phil Endecott <spam_from_boost_dev(a)chezphil.org> > Subject: Re: [boost] [fixed_string][review] Review of fixed_string > Message-ID: <142EED34-B802-4381-9FF9-C9FE999BA0F9(a)ptd.net> > Content-Type: text/plain; charset=utf-8 > > > > On December 5, 2019 9:35:35 AM EST, Phil Endecott via Boost < > boost(a)lists.boost.org> wrote: > > Peter Dimov wrote: > > > - a function that checks whether the remaining capacity is at least > > n should > > > be added. I suggest the name > > > > > > bool can_fit( std::size_t n ) const noexcept; > > > > > > although my previous choice of "has_capacity_for" has merit too. > > I suggest the simpler "fits". > > > Make this a free function template and you can use it with other > > containers: > > > > template <typename CONTAINER> > > bool can_fit( const CONTAINER& C, typename CONTAINER::size_type n ) > > noexcept > > { > > return C.capacity() - C.size() >= n; > > } > > That's a nice idea, especially with the name "fits". :) However, if you > reverse the parameters, "fits_in" would be a better name as it indicates > the argument order. > -- > Rob > > (Sent from my portable computation device.) > > > ------------------------------ > > Message: 2 > Date: Sun, 8 Dec 2019 01:25:04 +0100 > From: Mateusz Loskot <mateusz(a)loskot.net> > To: boost(a)lists.boost.org > Subject: Re: [boost] Extending GIL > Message-ID: > < > CABUeae_cupOMOhCNvvHaeruX2ksycHhVKkHJbtCSCLr-kW-XkA(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Sat, 7 Dec 2019 at 01:12, Siddhartha Sen via Boost > <boost(a)lists.boost.org> wrote: > > > > Having looked up this repository : > https://github.com/boost-gil/gil_threaded, > > I feel the idea was the same, but a lot of improvement can be made. > > Good, sounds like you may have a plan in mind > > > Also, there was no provision for image conversion, which I feel > > Please, you need to be more specific here. > What kind of conversion do you mean: color, channel/pixel type, format,...? > > p.s. I forwarded your post to the GIL mailing list > https://lists.boost.org/boost-gil/2019/12/0362.php > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > ------------------------------ > > End of Boost Digest, Vol 6271, Issue 1 > ************************************** >

2 1

[release] 1.72.0 post-beta merges
by Michael Caisse 08 Dec '19

08 Dec '19

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>

11 31

[range] Trying to extend boost::range::combine to std::tuples
by Andres Llopis 08 Dec '19

08 Dec '19

Hi everyone, I am trying to make my own version of combine so that it works also with std::tuples. Someone on slack suggested that the zip iterator should be able to handle it properly. My attempt however fails when trying to use the metafunction tuple_of_references::type for the std::tuple of iterators. This is what I tried (https://godbolt.org/z/Ymjtvn) (Please excuse any style problems, this is my first post) namespace myns { using boost::iterators::zip_iterator; using boost::iterator_range; template<typename IterTuple> class combined_range : public iterator_range<zip_iterator<IterTuple> > { typedef iterator_range<zip_iterator<IterTuple> > base; public: combined_range(IterTuple first, IterTuple last) : base(first, last) { } }; template<typename... Ranges> auto combine(Ranges&&... rngs) -> combined_range<decltype(std::make_tuple(std::begin(rngs)...))> { return combined_range<decltype(std::make_tuple(std::begin(rngs)...))>( std::make_tuple(std::begin(rngs)...), std::make_tuple(std::end(rngs)...)); } }

3 5

Extending GIL
by Siddhartha Sen 08 Dec '19

08 Dec '19

Having looked up this repository : https://github.com/boost-gil/gil_threaded, I feel the idea was the same, but a lot of improvement can be made. For example, by using OpenMP, I feel the computational performance can be massively improved and that too, not requiring any extremely sophisticated hardware. Also, there was no provision for image conversion, which I feel is a very good extension. What do you all think?

2 1

[fixed_string][review] Review of fixed_string
by Peter Dimov 07 Dec '19

07 Dec '19

This is my review of FixedString. * Summary The library should be ACCEPTED. It's useful, for more than one domain, and specifically where compile-time string manipulation is concerned, everyone needs to reinvent it. The name fixed_string is fine as is. Alternatives exist, but I don't see any of them as unquestionably better, and one becomes accustomed to "fixed_string" after a very brief period. Throwing on exceeding capacity is fine as is. A function should be provided to check the remaining capacity, because writing this check by hand is very easy to get wrong, and in fact the library throughout its implementation consistently gets it wrong. * Documentation The documentation is adequate, but I don't find the reference convenient. I would prefer a synopsis that contains the entire class definition of `fixed_string`, so that I can see the various overloads at a glance. Instead, the synopsis only gives me the declaration of `fixed_string`, without even telling me what namespace it's in. (It also gives me `basic_string_view`, also without mentioning the namespace.) The current layout is fine if I want to look up a specific function by name. The format should ideally follow the standard library, with Throws and Expects clauses (the latter instead of "undefined behavior unless".) It's not documented when constructors and assignment operators throw. * Design - static_capacity should be removed; capacity() and max_size() should be static constexpr. - all nonthrowing functions should be marked `noexcept`. - initializer_list<CharT> overloads are of dubious utility. I know that the design copies std::string here, but I think that we should deviate and not provide them. - substr() should return a fixed_string, subview() a string_view (as already implemented.) - operator+ should be provided, only for arguments with capacity known at compile time (fixed_string<N>, CharT and CharT const (&)[ N ]), with the capacity of the result being the sum of the capacities of the arguments. This is not very useful for long strings, but it's fine for short strings, useful for compile-time manipulation, and useful in simple cases such as to_fixed_string( n ) + " bytes written". - a function that checks whether the remaining capacity is at least n should be added. I suggest the name bool can_fit( std::size_t n ) const noexcept; although my previous choice of "has_capacity_for" has merit too. This is, in my opinion, an absolutely necessary addition, because of my already-stated observation that the check is almost always gotten wrong. Here for instance is an example: if(size() + count > max_size()) BOOST_FIXED_STRING_THROW(std::length_error{ "size() + count > max_size()"}); The correct way to write it is max_size() - size() > count, which avoids the integer overflow in size() + count. In this case, passing count = (size_t)-1 will pass the check (when size() > 0) and then lead to undefined behavior. This makes the utility of reserve() dubious, because it basically invites one to get it wrong, but I think we should retain it for consistency. - everything should ideally be constexpr. The problem here is that constexpr requires initializing all elements, and this will heavily penalize runtime uses of f.ex. fixed_string<512>. On compilers with __builtin_is_constant_evaluated (gcc 9, clang 9) we should use that; otherwise, it might be worth it to create a specialization for N < some suitable upper limit. Again, any nontrivial string manipulation at compile time basically requires a fixed_string. * Implementation The physical separation of the library into three headers is inconvenient. A single header would make it possible to include the library directly on Godbolt via https, which is useful for both demonstrations and analysis of the generated code. In addition, hunting down the definitions is irritating for people reading the code. The reverse is true for the tests; they should be split into files each testing a logical group, such as constructors, assignment, append, and so on. The helper functions "testAS", "testI" and so on make reading the tests unnecessarily cryptic (and is quite annoying for reviewers.) They should have been named "test_assign", "test_insert". It's generally better to use `BOOST_TEST_EQ(s.size(), 0);` instead of `BOOST_TEST(s.size() == 0);` because the former prints the values on failure, which often gives clues as to where the error is. The test functions shouldn't be in the boost::fixed_string namespace. Users don't write their code in this namespace, so the tests don't test what users use. All capacity checks should be either audited for correctness and fixed, or use the proposed can_fit addition. Instead of repeating BOOST_FIXED_STRING_THROW(std::length_error{ "n > max_size()"}); in every function, which leads to it being inlined there repeatedly, this could use a helper function void throw_length_error( char const * msg, boost::source_location const& loc ) { boost::throw_exception( std::length_error( msg ), loc ); } taking advantage of the new boost::throw_exception overload that takes a source location as documented in https://www.boost.org/doc/libs/develop/libs/throw_exception/doc/html/throw_…. A variation could take `n` as an argument and compose a message containing it, f.ex. void throw_length_error_fmt( boost::source_location const& loc, char const * fmt, ... ); #define BOOST_FIXED_STRING_USE_BOOST should go, as already mentioned. Since the library requires C++11, there's no need to use BOOST_STATIC_ASSERT. static_assert is fine. Unless of course we backport it to C++03, which might be doable, although of questionable utility. Checking for overlap and using Traits::copy instead of Traits::move isn't needed. Traits::move does the same check anyway, so there's no gain, just an opportunity to get the check wrong and introduce undefined behavior. "The behavior is undefined if `count >= npos`" doesn't seem necessary. In this case, count will be bigger than max_size() and the constructor will throw std::legth_error. There's no reason to gratuitously introduce undefined behavior. All "undefined behavior" cases should consistently BOOST_ASSERT.

4 4

[nowide] Future
by Artyom Beilis 07 Dec '19

07 Dec '19

The nowide library was reviewed and accepted into Boost almost 3 years ago. I implemented most of fixes required under Review Fixed branch https://github.com/artyom-beilis/nowide/tree/reviewfixes Unfortunately I don't have any capacity to do maintenance for it on all various platforms: MSVC, mingw. cygwin etc mostly because virtually I don't develop on Windows and any time I need to go there I need to figure it out from the beginning (installations, environment, msvc) and I don't even have windows machine in my hands (all done in VM) I realized that I'm not windows developer any more and it would be impossible for me to complete the mission of maintaining the code mostly due to personal reasons and lack of development resources. I deeply regret wasting the time and effort of so many boost developers who invested to review. I understand that it is highly desired library but I just can get the job done I seek for your advice. Do I need to seek for an another maintainer or withdraw the library entirely? Once again sorry for disappointing the community and people who were invested in this library. Artyom Beilis

6 10

[review][fixed_string] End of review period approaching and a plea
by Joaquin M López Muñoz 06 Dec '19

06 Dec '19

The review period for candidate Boost.FixedString finishes tomorrow, Dec 4. There's an ongoing lively discussion on many aspects of the library, which is very good, but only three of you have cast your acceptance/rejection vote, which is not good. This is a gentle petition to the people engaging in the review who haven't voted yet: Vinícius, Nevin, Mike, Andrzej, JeanHeyd, Hans, Peter, Julien, Andrey, Tim, Gavin, Emil, (and anyone who might be still lurking) to please submit a review with an explicit vote. If you feel like you need some more time to do the work, I think we are in a position to extend the review period, but please express your intentions before I ask the review wizards. Thank you! Joaquín M López Muñoz Review manager for candidate Boost.FixedString

13 35

[release] Boost 1.72.0 Release Candidate 1
by Marshall Clow 05 Dec '19

05 Dec '19

The first release candidates for the 1.72.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.72.0/source/> The SHA256 checksums are as follows: fcd8b598bc63ae7bbd3e72635d95b9d749ef65f4e5342c24445ea1fb9d417ac3 boost_1_72_0_b1_rc1.7z f6a527a261e273bfd2b6161d359ab9fb53c1795239c696f501a62f575cd30bda boost_1_72_0_b1_rc1.tar.bz2 8e591146d39e8cb45c74540aae26ae6321b1e83ab1b12e236dd117f93475ceb9 boost_1_72_0_b1_rc1.tar.gz 3425e7bfd49a6ad70aa7e82c1c740f7821eb58d14604b133be4dfbcdc0c58e3a boost_1_72_0_b1_rc1.zip 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 Boost Release Managers

3 10