November 2018 - Boost - lists.boost.org

interest in a flag library
by Masse Nicolas 05 Nov '18

05 Nov '18

Hi all, This is the first time I post on this mailing list :). I'm posting because i'd like to know if people would be interested in a library to treat enum types as flags. I find that's something which is lacking in the language since the introduction of strongly typed enums, and I've since written some code in order to do this. So far I've seen some discussion on this mailing list about that, but it doesn't seems that any library have been written yet. So do you think it is worth the effort of porting and documenting my code so that it can integrated into boost, or not? Regards, Masse Nicolas. PS: For those interested, the code consists of a flag class, and overloads operators like '|' or &. It can be used like this: enum struct option : uint { none = 0, first = 1, second = 2, third = 4, forth = 8 }; static constexpr flags<option> var1 = option::first; static constexpr flags<option> var2 = option::second | option::third; static constexpr auto var3 = var1 | var2; /* type will be resolved into flags<option> */ static constexpr auto var4 = option::first | option::second | option::third; /* works too */ int main() { std::cout << var1 << std::endl; std::cout << static_cast<uint>(var2) << std::endl; /* note that static_cast<int> won't compile since the underlying type is uint */ std::cout << (var3 & option::forth) << std::endl; std::cout << (var3 == var4) << std::endl; return 0; }

8 9

Boost.CI for Boost Repository Build Quality
by James E. King III 05 Nov '18

05 Nov '18

Continuous Integration is a modern cornerstone of delivering quality results in software engineering. When I started getting involved in boost as a maintainer (instead of a long-time consumer) it became a goal to get CI into as many repositories as possible. CI allows submitters to self-check their code changes without bothering the maintainer(s) of each repository. It eases the burden for maintainers as they can focus more on code review, and less on manual machinations to validate changes (by running code locally in their own environments). The wide coverage of builds in Boost.CI has helped identify a number of issues and improved the quality of those repositories. Performing these tests and analyses before code is merged catches issues earlier (but is not as comprehensive as the test matrix in terms of platform support due to limitations in the CI providers). Given that the Travis CI and AppVeyor builds for almost all the CMT repositories (and a few others) are using Boost.CI, it's proper place is under the "boostorg/" GitHub organization. Right now it's under my GitHub account, but I would like to move it to a more official location. https://github.com/jeking3/boost-ci Thanks, Jim

3 4

Draft copy - Call for Submissions - CMake for Boost
by Robert Ramey 05 Nov '18

05 Nov '18

The following is a draft of the document of I have planned to post on behalf of Boost on or around 1 November 2018 as the first step in our next attempt to accommodate CMake in Boost. Robert Ramey Call for Submissions - CMake for Boost ====================================== For some time, there has been interest on many users and developers of Boost Libraries to make Boost easier to use with CMake. Discussions in the past have not resulted in an implementation which has been widely accepted. Never the less, hope springs eternal, and we intend to attempt this once again. It seems that often there are difficulties before such projects even start in that there are wide discrepancies as to what should be the goals and expectations of Boost support of CMake. The aim of this document is to try to build a consensus on this question before encouraging CMake developers and experts to submit proposals for Boost support of CMake. Requirements and Scope ====================== Requirements ------------ Submissions will fulfill the applicable requirements of any boost submission. This will include: a) any necessary code. b) specifications/requirements for things like directory structure and contents. b) A useful document. Document should provide information, examples and templates so that a typical C++ and CMake user should be able to do any of the following in a short time - say 10 minutes. Document at a minimum should be viewable as html and/or PDF file. 1) A library user should be able to incorporate a Boost Library into the CMake script. 2) A library user should be able to determine which additional Boost Libraries he needs. 3) A library developer should find it simple to create the requisite CMake files for his library. Thus the documentation should contain explanation and perhaps other means such as examples and/or "templates" for required CMake files. c) test of CMake facilities supported by the CMake implementation. This will include code, test of any features, capabilities that the submission provides. Users expect that if they follow the instructions in the documentation, they will get the promised results. A manner of proving this must be provided. A likely response to this requirement would be a "test project" which can be used to demonstrate that the submission actually works. This will be useful in the future for maintenance of the CMake Boost implementation. It will permit the maintainer of the Boost.CMake facility to work on and test their fixes and improvements without disrupting other developers and users. d) a Boost License Facilities and features ----------------------- CMake as it stands has lots of capabilities. But it has a fair amount of complexity as well. Lots of things can be accomplished in multiple different ways - each with subtly different results and effects. CMake for Boost will likely consist of documentation, examples, CMake code, and other stuff to use CMake to permit new features and facilities for users and developers of Boost libraries. What follows is a list of facilities that Boost users and developers would like to acquire with CMake for Boost. Those marked with * should be considered hard requirements. That is, submissions which don't include this feature can't be considered. Other items are interesting and would be considered if included in a submission. *a) incorporating selected Boost Libraries into a user's application *b) incorporating selected Boost Libraries into a user's library c) building a boost library d) building a boost tool such as Boost.bcp, Boost.boostdep, etc. e) testing a boost library - if testing of Boost libraries is to be supported, the following features should be considered. Those marked * should be considered essential. *1) execution tests - must pass/ must fail *2) compile only tests - must pass/ must fail *3) link only tests - must pass/ must fail 4) should be available to both users and developers 5) should not depend upon tools other than C++. 6) test should have the option of posting the results to some public "dashboard" 7) option for recursive testing and/or building of libraries might be nice. That is if library A uses library B and I test library A, this would automatically test library B beforehand. *f) In CMake, dependent libraries are specified as part of the library CMakeLists.txt files. There several ways to do this and the subject is pretty confusing to get right. Any submission documentation has to explain to library developers how do this. g) Some have suggested a highly automated process including downloading/updating, finding other components on other machines, etc. This shouldn't be considered h) packaging - preparation of distributable, installable files for various operating systems. That is support for the CPack facility. i) There has been a lot interest and work in automatically determining dependencies It's a much deeper subject than most people realize. Solving this problem is not a requirement of the submission. However, submitters are free to address this if they desire. *j) support of library modularity. This would mean: *1) independence of things outside the library directory structure. To wit - no presumption about any "super project". *2) building out of tree *3) no need for installing libraries not used by the build target k) ... Submission Rules and Procedures ------------------------------- a) This document constitutes a "Request for Submissions". It will be announced on the boost announcements list, boost developer's list, slack/boost, isocpp website and twitter account, reddit at r/cpp. Submissions will be open to anyone. b) Submissions will be accepted at an email address to be specified. Received submissions will receive a "prescreening" to determine that they meet the requirements specified for such submissions at the top of this document. Those that don't will be returned to the author. c) The name of the author of a submission will not be included in the submission. Authors will be expected to take reasonable efforts to maintain his anonymity via a github repo without a real name assigned, anonymous, email address etc. We understand that the nature of the submission and debate during subsequent review of the proposals. Never the less we believe that anonymity can be mostly maintained. The the true identity of the author of the selected proposal will not be revealed until the selection is made. The motivation for this anonymity is to attract submitters who find the boost review process distressing, annoying and/or unpleasant. It should also address the concerns of those who beleive that by not being a "boost insider" they won't get fair consideration. Boost is first and foremost a meritocracy. We seek the very best in everything regardless of other considerations. d) Submissions will be closed on or about 1 February 2019. Boost formal review will commence shortly there after. Depending on the number of submissions received, the process may last as long as month. e) As per the boost formal review rules and customs, some time after the review period terminates, the review manager will announce the review results. This will likely contain some conditions regarding alterations required in the submissions implementations. I the author find these too onerous, and declines the opportunity to integrate his submission as an official part of boost, the review manager may select an alternate submission. It's also possible that the review manager may decide to accept none of the submissions. f) when the submission is integrated into boost and is shown fulfill the requirements stipulated by the review manager. The author will receive a "prize" of $5000 and a large but cheap medal on a ribbon hopefully to be awarded at the next C++Now (Boost Con). As this is written, this prize is subject to finding a funding source. It's understood that this stipend is in no way compensation, for all the work and aggravation of this task. But we hope that it will serve as a tangible token of our gratitude for solving one of Boosts most pressing and difficult problems. Useful Resources =============== “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1 https://github.com/purpleKarrot/Boost.CMake https://steveire.wordpress.com/2016/08/21/boost-dependencies-and-bcp/

10 28

Has anyone thought about adding a general case subset class?
by jrmarsha 04 Nov '18

04 Nov '18

I've got a lot working with my madlib version of graph, but I've been thinking over the elegant ways to add the subgraph feature in BGL. It occurred to me that this can be phrased as a more general problem as container subsets. And while we're at that, then we can add objects or operators for set operations like inner join, left join, and outer join. Can I get some thoughts?

1 0

Fwd: Errors in test matrix
by Stefan Seefeld 03 Nov '18

03 Nov '18

[I haven't received a reply on the boost-testing list, so I'm resending to the general list in the hopes that someone can help.] -------- Forwarded Message -------- Subject: Errors in test matrix Date: Wed, 31 Oct 2018 09:41:05 -0400 From: Stefan Seefeld <stefan(a)seefeld.name> To: Running Boost regression tests <boost-testing(a)lists.boost.org> Hello, [I'm not entirely sure this is the right place for the report. Please let me know if it isn't, and where to post instead.] On https://www.boost.org/development/tests/develop/developer/numeric-ublas.html, I'm looking at failures in the "Sandia" columns. Following one link takes me to https://www.boost.org/development/tests/develop/developer/output/Sandia-gcc…, which demonstrates a couple of issues: * What compiler version is this using ? The URL contains both "5.4.0" as well as "4.4.7". * The actual error reads "unrecognized command line option -std=c++11". Given that Boost.uBLAS itself doesn't specify this flag, I assume it's part of the test runner's configurations. However, it seems to be used with a compiler version that doesn't support it (though again, it isn't clear which compiler version we are actually talking about). Unfortunately there are quite a large number of columns with similarly generic errors, i.e. errors more likely to be caused by invalid set ups, rather than genuine errors in the library (libraries, as I'm seeing similar errors in other libraries). What can I do about this ? Ignore the errors ? It would be good if the metainfo that is displayed with the test runners included a point of contact (mail address ?) to report such errors. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

2 1

Re: [boost] [parameter] Go C++11 and above only, or keep C++03 support?
by Nikita Kniazev 03 Nov '18

03 Nov '18

The major problem is that Boost does not see its users; most of them do not read mail lists and changelogs, even documentation is read only during active development and by developers who actually touches boost namespace. To library maintainers they usually appear only when something is completely broken and we cannot blame anyone about it, but it makes nearly impossible to gather any statistics. The other point is that Boost is free and users may decide not to raise their voice because it can look like they try to dictate investment priorities of others spare time. If Boost really wants to survey C++03 users it can be most effectively done in the code by showing them a message with a conditional pragma #error “Boost wants to hear your voice. It is time to revise the minimal requirements. Please give us feedback about your preferences at <url> or mail list. To continue #define BOOST_I_ACKNOWLEDGE_EMERGING_CXX03_DEATH” in some libraries or globally in Boost.Config headers. It is not too late to make this for 1.69.

2 1

[release] 1.69.0 closed for major changes
by Marshall Clow 01 Nov '18

01 Nov '18

The master branch is now closed for new libraries and breaking changes, and will be closing for the beta in one week. Also, if you're ready, you can also add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_69_0.q… > After editing the release notes, you should get a form to create a pull request, remember to submit it, otherwise I won't see your change. Thanks, -- The Boost Release Team

1 0