- Boost - lists.boost.org

Current Guidance on Compiler Warnings?
by Brian Kuhl 29 Nov '18

29 Nov '18

I'd like to confirm the guidance on Warnings I find here https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines is still considered current? context ... At Wind River we are in the process of working with Boost 1.68 and VxWorks 7 (with Dinkum 7.00 with and Clang 6.0 for ARM and IA boards and GCC 8.1 for PowerPC ) with the hope of bundling Boost with our product. Many of our customers make certified systems ( Planes, Trains, Medical Equipment, Factory Automation, etc. ) and the trend in theses industries is to be pedantic about eliminating all compiler warnings. While we have not traditionally required zero warnings in open source code shipped with our product, there is pressure on us to move in that direction, and as result we will probably be contributing pull requests specifically to fix or suppress compiler warnings over the coming years. I'd like to establish clear guidelines for my team as to what is an appropriate "coding standard" for Boost in regards to compiler warnings. While it is simple to say, everything displayed by -Wall, in practice there are many edge cases, e.g. is an unused parameter acceptable in test code? So I'd like to get the maintainers guidance. Many thanks Brian Kuhl

23 103

[graph] Tree data structure
by Jeremy Murphy 28 Nov '18

28 Nov '18

Dear Boost community, long ago, back in 2002 and 2009, Kasper Peeters proposed adding his tree data structure to Boost. http://tree.phi-sci.com/ There was a lot of discussion but nothing eventuated (so far as I am aware). There are links to the historical discussions on his website. ...2018.... Recently, a Boost.Graph user suggested adding a tree class to it, and I was like, "No, no, a tree is just a graph that satisfies certain constraints: a tree class won't yield better performance." But I also happen to be re-reading for nth time, Element of Programming, which touches ever so briefly but intensely on binary trees, and I realized "Oh, hold on, there is a world of conceptual difference between an arbitrary tree, and a k-ary tree." That discussion is here: https://github.com/boostorg/graph/issues/123 It seems very awkward to even try to represent a k-ary tree in existing Boost.Graph data structures, let alone a mutable k-ary tree. So I made a proof-of-concept, a mutable k-ary tree data structure with specialized implementations of depth-first search and isomorphism. Unless I've made a terrible mistake (which is possible), the performance gains are huge, and the ease of use in an existing library is also huge. OK, so huge things aside, this is really early days, exploratory work. And I'm no Boost.Graph expert. I'm interested in what people think, particularly whether they think it is an idea worth pursuing. I do. But I basically need help from people smarter and more experienced. I have made a PR for the sake of discussion, not for actually merging: https://github.com/boostorg/graph/pull/139 Cheers. Jeremy

1 0

[threads] Launch deferred for async
by Stephan Menzel 28 Nov '18

28 Nov '18

Hello all, I am using boost::async() to create futures from tasks in order to wrap some behavior that may or may not be sync. This behavior is implemented behind an interface and can be small and fast operations or longer running and blocking things. All return a future as a result type, so I can hide the ugly truth. For the smaller stuff I'd like to use launch::deferred to avoid threading altogether and just execute the task when the user get()s the future. boost::future<bool> ret = boost::async(boost::launch::deferred, [this] () -> bool { // do some small cpu only impl return result; }); But when i get the result: const bool result = ret.get(); ...the application crashes. Debugging this I came to this in boost/thread/future.hpp:9373 } else if (underlying_cast<int>(policy) & int(launch::deferred)) { std::terminate(); //BOOST_THREAD_FUTURE<R> ret; //return ::boost::move(ret); // return boost::detail::make_future_deferred_shared_state<Rp>( // BF( // thread_detail::decay_copy(boost::forward<F>(f)) // ) // ); } else { To me this sounds like the application will always std::terminate() when launch::deferred is chosen. Why is that? When I use launch::any it seems to work but why is there a parameter that always yields unwanted results. What is the reason behind it? Can I get launch::deferred as it is described (not threading, just executing the task sync when get() is called) somehow? Platform is x64 Windows 10, MSVC14.1. Cheers, Stephan

2 4

[release] 1.69.0 post-beta merges
by Marshall Clow 26 Nov '18

26 Nov '18

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/Release-Beta-Merge-Policy> The master branch will close for the 1.69.0 release on 5-December. The release calendar is at https://www.boost.org/development/index.html -- The Boost release team.

8 17

[release] 1.69.0 post-beta merges
by Oliver Kowalke 26 Nov '18

26 Nov '18

Hi, boost.context needs a post-beta merge in order to fix some issue on ELF asm. Do I get permission to merge to master? best, Oliver

2 1

Guidence on #pragma once
by Robert Ramey 25 Nov '18

25 Nov '18

In the safe numerics library my *.hpp files start with the following boiler plate: #ifndef BOOST_NUMERIC_AUTOMATIC_HPP #define BOOST_NUMERIC_AUTOMATIC_HPP // MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) # pragma once #endif ... I would like to replace all this in every file with just #pragma once according to https://en.wikipedia.org/wiki/Pragma_once#cite_note-9 this should be possible while supporting almost all which claim to be C++ 14 conformant. The exception noted is C++ for Cray. I realize that strictly speaking I shouldn't do this. But it would instantaneously remove some cruft from my code as long as the occasional error from repeating the same include guard text in multiple files. It might have some performance benefits and some other repercussions related to pre-compiled headers. Who knows what else. It would be interesting to know what others might have to say about this. Robert Ramey

10 10

[Boost][DoubleEnded] Status?
by degski 25 Nov '18

25 Nov '18

We had the review of this library proposal/addition quite a while back and ever since I've been [eagerly] waiting for its official entry into Boost. https://github.com/erenon/double_ended does not show any activity and there is nothing in the Boost.Container going on either. What is the status? degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*

4 6

Geometry path length breaking windows regression runs
by Tom Kent 23 Nov '18

23 Nov '18

There has been a change to the geometry library, sometime around Nov 14, that is causing the windows regression runners I manage to crash. The issue is that it is creating *very* long filesystem paths, even with the regression --abbreviate-paths option set. There are a bunch of files such as: D:\teeks99-08\run\results\boost\bin.v2\libs\geometry\test\self_contained_headers\self-contained-algorithms-detail-buffer-buffered_piece_collection~hpp.test\msvc-14.1\dbg\adrs-mdl-64\async-excpt-on\thrd-mlt\self-contained-algorithms-detail-buffer-buffered_piece_collection~hpp.obj.rsp That seem to be created alright, but when I try to cleanup the run afterwards, windows doesn't allow me to delete the files. Tom

5 4

Help - my disk is full! (of bin.v2 stuff)
by Paul A. Bristow 21 Nov '18

21 Nov '18

I note with surprise (and alarm) that my Boost-stuff disk partition is nearly full! Closer inspection reveals that I have a bin.v2 folder of over 50 GB. Obviously, I need to delete something. What are the implications of deleting things? What is the best option? Should I simply delete the whole folder bin.v2 (I have, in desperation, gone nuclear some time ago) or just bin/v2/libs or ? Expert advice welcome. Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

5 4

Rotating on-call review managers
by Zach Laine 19 Nov '18

19 Nov '18

Boost was originally created to incubate libraries that target eventual standardization. When new libraries are proposed, many of the Boost community members that participate in C++ Standard Committee (WG21) meetings ask "How many users does this have, and did you consider Boost first?" Often the answer is that they considered Boost but could not figure out what they were supposed to do to make that happen, or that they had difficulty finding a review manager. There are other things that can be done to make getting a library Boost-review-ready, but most of them require a bit of work up front. The review manager requirement is relatively easier to satisfy. This volunteer effort is to better facilitate Boost's value in the ISO C++ standardization process and so the reviewers would need to recognize intent to standardize the proposed libraries. Submissions that are supported with a paper in a mailing or a draft will make it easier to source a review manager from this queue, but authors without either are encouraged to get in contact with reviewers on this list to find out what that entails. This is the list of volunteers: Zach Laine Micheal Caisse Matt Calabrese Louis Dionne Vinnie Falco Glen Fernandes Jeff Garland David Sankel The list will rotate; the first person on the list will be "on-call". If you'd like to help, let me know and I'll add your name to the list. Also, I've made a PR that adds this list and a note like the description above to https://www.boost.org/development/submissions.html (#6 Seek a Review Manager): https://github.com/boostorg/website/pull/387 Zach

2 2