- Boost - lists.preview.boost.org

[boost 1.61 - [thread] Request for permission to merge
by Vicente J. Botet Escriba 31 Mar '16

31 Mar '16

Hi, I would like to merge once it is announced that the release branch is open for fixes a minor fix https://svn.boost.org/trac/boost/ticket/11562 - (condition_variable_any::wait_until + recursive_mutex + steady_clock) timer expires after computer time is set forward on Ubuntu 64-bit add missing template parameter in wait_until. https://github.com/boostorg/thread/commit/9db70b803d8f45632cd92cd61ab019c1f… and the rollback of something that resulted in a regression https://svn.boost.org/trac/boost/ticket/12049 - Assertion failure from detached threads during shutdown rollback BOOST_THREAD_PATCH. https://github.com/boostorg/thread/commit/47357de276fe4fc01469f34c1dbf8b26f… Best, Vicente

1 1

Re: [boost] [filesystem] Horrible documentation
by Tatsuyuki Ishi 31 Mar '16

31 Mar '16

> From: Edward Diener <eldiener(a)tropicsoft.com> > Date: Wed, 30 Mar 2016 00:06:00 -0400 > Subject: Re: [boost] [filesystem] Horrible documentation > > What sort of documentation unification with other libraries do you mean ? By saying unification, I'm talking about the green-background header. It's in most documentation and also on the homepage. > Can you not increase the font size, if it is too small for you to read, in your preferred browser since the doc is HTML ? The layout is quite problematic. Not only the font, text breaks border, and the page is too tall(long). I noticed it's created with FrontPage 2002. Come on, this is 2016.

3 2

[release] Download data
by Daniel James 31 Mar '16

31 Mar '16

Hi, Currently the download details for a release are included in the quickbook source file for the release notes, which is a bit wonky, and makes it tricky to add extra data, so I'm thinking about storing it separately. This should make it easier to add things like hash signatures and links to third party downloads, such as the windows binaries. So I'm thinking about how to make it easy for people to add the details of their downloads. Could possibly create an extra file for each release, and then people can add data using pull requests, much as we've been using pull requests on the quickbook files, which seems to work fairly well. Another possibility is that we could pull in the details from the server's API, although I don't really fancy having to support multiple data sources with different APIs. Any other ideas? Also, is there any way in which you'd like me to make this kinds of information available for your scripts, packaging etc. Here's a rough version of how the internal data might be stored in a JSON file (other file formats are possible): { 'version': '1.61.0', 'status': 'beta', 'release-notes': '/feed/history/boost_1_61_0.qbk', 'documentation': '/doc/libs/1_61_0/', 'downloads': [ { 'url': 'http://..../boost_1_61_0_beta1.tar.bz2', 'hash': '484c635.....' }, { 'url': 'http://..../boost_1_61_0_beta1.7z', 'hash': 'f93de8.....' }, // ... ], 'third-party': [ { 'url': 'http://...', 'title': 'Windows binaries', 'whatever_else': '' } ] }

1 0

[filesystem] Horrible documentation
by Tatsuyuki Ishi 30 Mar '16

30 Mar '16

Sorry for complaining. Is there any plan to use any documentation tool to regenerate this? It's not unified with other libraries, and too horrible due to the small font size. I really can't read that.

2 1

[Root Pointer] Benchmark w/ Threading = 124% faster
by Phil Bouchard 30 Mar '16

30 Mar '16

I just noticed that if I do not define the BOOST_DISABLE_THREADS macro, root_ptr is faster than allocate_shared_noinit by 124%: unique_ptr (new): 42.1397 unique_ptr (make_unique): 43.4631 shared_ptr (new): 76.4543 shared_ptr (make_shared): 76.6611 shared_ptr (allocate_shared_noinit): 81.9926 root_ptr (new): 66.3417 Thanks, -Phil

1 2

Fwd: [sort parallel] New Parallel Sort Algorithm
by Francisco José Tapia 29 Mar '16

29 Mar '16

This message is for to announce the new version of the Boost Sort Parallel algorithms. You can find in http://github.com/fjtapia/sort_parallel. In the documentation, you can see the description of the algorithms, examples of invocations, and the graphs of the benchmark of the algorithms. The benchmark was not include in the library. I created other repository https://github.com/fjtapia/sort_parallel_benchmark, where you can find the code of the benchmark, the library, and the external code of the TBB parallel stable sort. It was not logic, include external code inside the library. The most significant of this version is the new parallel sort algorithm (internally named Block Indirect Sort) In the Parallel Sort Algorithms, we can find two groups. - Algorithms very fast with many threads (GCC Parallel Sort, Microsoft Parallel Buffered Sort), but use an additional memory as the data. - Algorithms without additional memory, but slower with many threads (TBB Parallel Sort, Microsoft Parallel Sort) The new algorithm *invented, designed and implemented by the author, provide the speed of GCC Parallel Sort and a memory usage similar to TBB. With the additional advantage that don't need any library ( Open MP , TBB, Microsoft PPL …). Only need a C++11 compiler. An example shows you this : Sorting 100 000 000 random numbers of 64 bits. In a server with 32 threads. The results obtained was *Time spent* *Memory used (MB)* *GCC Parallel Sort* 1.05 secs 1560 MB *TBB Parallel Sort* 1.76 secs 783 MB *Block Indirect Sort* 0.97 secs 790 MB In the repository with the benchmark code you can find the benchmark results with several machines https://github.com/fjtapia/sort_parallel_benchmark/tree/master/Linux64_GCC/… <https://github.com/fjtapia/sort_parallel_benchmark/tree/master/Linux64_GCC/…>In these files, you can see the rival is GCC. TBB is clearly surpassed, due to their internal algorithm. GCC divide the data, sorted independently by all the threads. And after for to merge do an easy process, and copy in an auxiliary memory, of the same size than the used by the data. All the threads are fed, but need the double of memory. The new algorithm, do the division, and sort independently, but for the merge, have a small buffer of 1024 elements, and when a part is moved to the buffer, must calculate which part must be copied in that place. Do the same but without the additional memory. Due this, need more CPU for to do the process. The hyper threading (HT) provide around a 30% more power to the processor, and usually in the machines with HT activate, the new algorithm is a bit faster than GCC, and with the HT deactivate is slower, and TBB is slower except when very big objects. But then the bottleneck is not the algorithm, is the data bus The new algorithm is a collection of bad algorithms when you have only 1 thread. But they are easily subdivided. This permit parallelize all the process and have fed all the threads. The new algorithm is documented in two articles - block_indirect_sort_brief_en.*:* (Introduction and graph benchmarks) - block_indirect_sort_en.pdf: (Introduction, detailed description of the algorithm and benchmarks.) If you want to test the benchmark in your machine it's easy. In the benchmark repository, you have the code used, and shell scripts for to compile and run, saving the results in a Results.txt file, for Linux GCC and CLANG and Windows Visual Studio 15 If you see any problem, mistake, something to improve or need any other information, please, say me. Yours Francisco * Invented: The algorithm had been ideate, designed and implemented beginning from zero from an old idea. After read hundreds of articles and books, I didn't find any similar. If you know something, please say me. But the important is not the author, is provide a fast, robust, and easy to use algorithm to the community of programmers.

1 0

[Boost 1.61] Open for bugfixes?
by Louis Dionne 29 Mar '16

29 Mar '16

Hi, On the release calendar [1], it is written that Boost 1.61 is currently open for bug fixes (since March 17). Some previous discussion left me under the impression that authors still had to ask a permission for pushing to their master branches. So, can I push (bugfixes) to Hana's master branch? Do I have to ask the permission when the calendar says it's open? Can I always rely exclusively on the official calendar at [1]? Thank you, Louis Dionne [1]: http://www.boost.org/community/index.html

2 2

[move][sort] Asymptotically optimal stable and in-place merging and sorting with no auxiliary memory
by Ion Gaztañaga 27 Mar '16

27 Mar '16

[Disclaimer, long e-mail, thank you for your attention] Hi to all, Some months ago I tried to gain interest from sorting experts about implementing stable and inplace merge [O(N)] or sort [O(NlongN)] algorithms that don't need additional memory. My main use case for these algorithms was lowering the complexity guarantees of range insertion functions offered by flat associative containers without any temporary allocation (the programmer does not expect allocations when capacity() is big enough to hold the new elements). On the other hand, I wanted those algorithms to be adaptive so as to take advantage of the extra capacity already allocated by flat containers. Of course, if a good implementation is available in Boost, it could be used as existing practice to change the worst-case complexities of some STL algorithms when no additional memory (e.g. get_temporary_buffer()) is available. After reviewing several algorithms from papers and some open source implementations, I decided to implement one of those algorithms. The implemented algorithm is based on the GrailSort algorithm developed by Andrey Astrelin. The main idea of the my adaptive_sort algorithm is explained by Andrey in an article published by the russian collaborative blog Habrahabr (http://habrahabr.ru/post/205290/) The algorithm is based on ideas explained by Huang and Langston in their paper "Fast Stable Merging and Sorting in Constant Extra Space (1989-1992" (http://comjnl.oxfordjournals.org/content/35/6/643.full.pdf) Since the implementation from (https://github.com/Mrrl/GrailSort) is macro-based, does not support non-memcopyable types and has a MIT license (which seems to be problematic for Boost), I implemented the algorithm from scratch following the article and taking ideas from Andrey's implementation. I added some new ideas and optimizations in order to reduce comparisons and elements moves. I must say that the implementation was really hard for someone like me without experience in sorting algorithms, the complexity is huge when compared with a classic mergesort algorithm. The implementation is already in develop and master branches but the develop branch contains more tests and a refactored and more documented code. So please check the code from the develop branch if interested. The implementation is still experimental and not production ready. What about benchmarks? I've only experimented in the oldest Visual compilers to make sure it correctly supports Boost.Move emulation and complexity guarantees were correct. Note that the STL algorithms tested in the benchmark might not be as fast as current implementations. In general, the new algorithms need much more elements moves than algorithms that allocate O(n) memory, but they are still quite fast when data movement is cheap (e.g. when a move constructor just copies a couple of pointers). These are the numbers for A VERY LIGHTWEIGHT object (a struct holding two integers, one for the key, another one to test the stability, don't take times very seriously, just pay attention to the number of comparisons/moves). ////////////////////////// ////////////////////////// STABLE MERGING ////////////////////////// ////////////////////////// - N: number of elements - NK: number of keys (0 means all keys different) - InplaceMerge: std::inplace_merge - Sqrt2AdaptMerge: adaptive_merge with an auxiliary buffer of 2*sqrt(N) elements - SqrtAdaptMerge: adaptive_merge with an auxiliary buffer of sqrt(N) elements - AdaptMerge: adaptive_merge with no external buffer - Cmp: number of comparisons / N - Cpy: number of move constructor/assignments / N - (ratio): time of execution / time needed by InplaceMerge ---------------------------------------------- Numbers produced by the bench_merge.cpp test in Boost.Move: ---------------------------------------------- - - N: 100001, NK: 511 - - InplaceMerge Cmp: 0.9989 Cpy: 1.5000 633.65us ( 1.00) Sqrt2AdaptMerge Cmp: 1.2429 Cpy: 4.4209 910.16us ( 1.44) SqrtAdaptMerge Cmp: 4.2708 Cpy: 5.6712 1.63ms ( 2.57) AdaptMerge Cmp: 5.6014 Cpy: 8.7573 3.11ms ( 4.91) - - N: 100001, NK: 2047 - - InplaceMerge Cmp: 0.9998 Cpy: 1.5000 604.77us ( 1.00) Sqrt2AdaptMerge Cmp: 1.2449 Cpy: 4.4483 934.83us ( 1.55) SqrtAdaptMerge Cmp: 2.0131 Cpy: 4.7609 1.12ms ( 1.85) AdaptMerge Cmp: 2.7608 Cpy: 11.1419 2.83ms ( 4.67) - - N: 100001, NK: 8191 - - InplaceMerge Cmp: 0.9999 Cpy: 1.5000 653.51us ( 1.00) Sqrt2AdaptMerge Cmp: 1.2443 Cpy: 4.3179 943.86us ( 1.44) SqrtAdaptMerge Cmp: 1.4661 Cpy: 4.4348 998.62us ( 1.53) AdaptMerge Cmp: 1.7692 Cpy: 10.6292 2.54ms ( 3.89) - - N: 100001, NK: 32767 - - InplaceMerge Cmp: 1.0000 Cpy: 1.5000 772.06us ( 1.00) Sqrt2AdaptMerge Cmp: 1.2417 Cpy: 4.4317 1.03ms ( 1.33) SqrtAdaptMerge Cmp: 1.3320 Cpy: 4.4758 1.06ms ( 1.38) AdaptMerge Cmp: 1.5295 Cpy: 10.1233 2.44ms ( 3.16) - - N: 100001, NK: 0 - - InplaceMerge Cmp: 1.0000 Cpy: 1.5000 881.88us ( 1.00) Sqrt2AdaptMerge Cmp: 1.2387 Cpy: 4.4124 1.16ms ( 1.31) SqrtAdaptMerge Cmp: 1.2933 Cpy: 4.4412 1.20ms ( 1.36) AdaptMerge Cmp: 1.4110 Cpy: 7.5794 1.93ms ( 2.19) In general, with no memory and enough keys, the algorithm needs 7,5*N data moves and 1,5*N comparisons. Data locality is quite high and with cheap-moving types the overall time can be just two-three times slower. With fewer keys, the algorithm might need upt to 5xN comparisons and 11xN moves. Number are improved if an auxiliary buffer of sqrt(N) elements is available. The number of comparisons and moves are even better than those shown in experimental results from several papers, but I still find them quite high. The algorithm needs some initial steps (e.g. unique key extraction) that are not amortized during the merge (adaptive_sort amortizes the initial steps much better ). I've derived the merge algorithm from the sorting algorithm so maybe there is room for improvement (I've invested much more time in the sorting algorithm). ////////////////////////// ////////////////////////// STABLE SORTING ////////////////////////// ////////////////////////// Numbers when sorting: - N: number of elements - NK: number of keys (0 means all keys different) - MergeSort: A half-copying mergesort (it only needs N/2 auxiliary memory) implemented in boost/move/algo/detail/merge_sort.hpp. Based on the paper "Fast mergesort implementation based on half-copying merge algorithm" by Cezary Juszczak (http://kicia.ift.uni.wroc.pl/algorytmy/mergesortpaper.pdf) Usually faster than std implementations with less auxiliary memory. - StableSort: std::stable_sort - HeapSort: std::heap_sort - QuartAdaptSort: adaptive_sort with N/4 auxiliary memory - Sqrt2AdaptSort: adaptive_sort with 2*sqrt(N) auxiliary memory - SqrtAdaptSort: adaptive_sort with sqrt(N) auxiliary memory - SqrtHAdaptSor: adaptive_sort with sqrt(N)/2 auxiliary memory - AdaptSort: adaptive_sort with no auxiliary memory - Cmp: number of comparisons / N - Cpy: number of move constructor/assignments / N - (ratio): time of execution / time needed by MergeSort [numbers produced by the bench_sort.cpp test in Boost.Move] - - N: 100001, NK: 511 - - MergeSort Cmp: 16.379 Cpy: 16.707 6.49ms ( 1.00) StableSort Cmp: 20.594 Cpy: 22.978 10.85ms ( 1.67) HeapSort Cmp: 16.992 Cpy: 22.098 10.98ms ( 1.69) QuartAdaptSort Cmp: 17.659 Cpy: 26.314 8.34ms ( 1.29) Sqrt2AdaptSort Cmp: 17.829 Cpy: 35.340 9.90ms ( 1.53) SqrtAdaptSort Cmp: 27.805 Cpy: 56.059 19.48ms ( 3.00) SqrtHAdaptSort Cmp: 27.356 Cpy: 60.375 20.35ms ( 3.14) AdaptSort Cmp: 27.352 Cpy: 67.889 21.83ms ( 3.36) - - N: 100001, NK: 8191 - - MergeSort Cmp: 16.394 Cpy: 16.725 7.47ms ( 1.00) StableSort Cmp: 20.578 Cpy: 22.978 11.92ms ( 1.60) HeapSort Cmp: 16.992 Cpy: 22.099 11.91ms ( 1.59) QuartAdaptSort Cmp: 17.676 Cpy: 26.362 9.26ms ( 1.24) Sqrt2AdaptSort Cmp: 17.847 Cpy: 35.747 10.93ms ( 1.46) SqrtAdaptSort Cmp: 18.977 Cpy: 41.641 12.19ms ( 1.63) SqrtHAdaptSort Cmp: 17.076 Cpy: 57.799 15.47ms ( 2.07) AdaptSort Cmp: 17.090 Cpy: 67.179 17.37ms ( 2.33) - - N: 100001, NK: 32767 - - MergeSort Cmp: 16.395 Cpy: 16.727 7.66ms ( 1.00) StableSort Cmp: 20.581 Cpy: 22.986 12.16ms ( 1.59) HeapSort Cmp: 16.994 Cpy: 22.099 11.96ms ( 1.56) QuartAdaptSort Cmp: 17.674 Cpy: 26.319 9.47ms ( 1.24) Sqrt2AdaptSort Cmp: 17.833 Cpy: 35.792 11.16ms ( 1.46) SqrtAdaptSort Cmp: 18.967 Cpy: 41.604 12.42ms ( 1.62) SqrtHAdaptSort Cmp: 17.065 Cpy: 57.756 15.71ms ( 2.05) AdaptSort Cmp: 17.081 Cpy: 67.131 18.32ms ( 2.39) - - N: 100001, NK: 0 - - MergeSort Cmp: 16.399 Cpy: 16.731 7.76ms ( 1.00) StableSort Cmp: 20.521 Cpy: 22.920 12.23ms ( 1.58) HeapSort Cmp: 16.991 Cpy: 22.094 11.85ms ( 1.53) QuartAdaptSort Cmp: 17.671 Cpy: 26.380 9.50ms ( 1.22) Sqrt2AdaptSort Cmp: 17.825 Cpy: 35.653 11.17ms ( 1.44) SqrtAdaptSort Cmp: 18.954 Cpy: 41.545 12.42ms ( 1.60) SqrtHAdaptSort Cmp: 17.058 Cpy: 57.694 15.66ms ( 2.02) AdaptSort Cmp: 17.072 Cpy: 67.072 17.57ms ( 2.26) In general, with no memory and enough keys, the algorithm needs nearly optimal comparisons and significantly more (4x) data movements. Data locality is quite high and with cheap-moving types the overall time can be just two-three times slower. With fewer keys, the algorithm performs worse but it's quite competitive. When extra memory (e.g. sqrt(N)) is available, the algorithm is quite fast with cheap-moving types. //////////////////////////////////////////// Final words: The effort to implement the algorithms was big and I couldn't fix many open bugs in my libraries, so in the following months I don't expect to invest much time on this. At least I wanted to publicly share the committed implementation so that it can be improved by sorting experts. I don't claim these algorithms are groundbreaking or even useful for many programmers, but they might be a good starting point. I'm not happy with the implementation as the algorithm is complicated and I' haven't found a way to simplify it further without noticeable slowdowns. For those interested in the implementation and the algorithm: please contribute correct benchmarks and testing, as there are very few open source implementations of similar algorithms. Any optimization, patch or bug report is welcome. Best, Ion

4 9

Boost 1.61.0 Beta 1 Release Candidate 2
by Vladimir Prus 26 Mar '16

26 Mar '16

Second set of release candidates for 1.61.0 beta 1 are now available: http://boost.cowic.de/rc/boost_1_61_0_b1_rc2.zip http://boost.cowic.de/rc/boost_1_61_0_b1_rc2.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_b1_rc2.tar.gz http://boost.cowic.de/rc/boost_1_61_0_b1_rc2.7z As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. The changes from RC1 are: * Top-level directory in the archive matches the name * Zip and 7z archives use CRLF line endings The known issues are: * Documentation build has some wrong-location, extra-files and broken-links issues. * There was a report of Boost.Context issue on OSX Release managers believe these issues are not blocking beta 1. The SHA1 checksums are as follows: 4d3c83d3a802d3dd12d4f2d516b3fcf076f6f6ba boost_1_61_0_b1_rc2.7z 8c6ac7326a3cabcabf6c7876052b73e0d41fc36d boost_1_61_0_b1_rc2.tar.bz2 e82b8ff7c3ad5b08c7dbeac1ea85fcf707a1cd4d boost_1_61_0_b1_rc2.tar.gz 7292e8fdac0566fe098a60a197a5722d381842d3 boost_1_61_0_b1_rc2.zip The SHA256 checksums are as follows: bc8341bfb8c6621319ad9eb732179fc7ec4da35c3cefc31b613f83ec3df10361 boost_1_61_0_b1_rc2.7z c0f06c78c195af9079773a2b250674244f1899ec81e84d5455f0761f1d888a16 boost_1_61_0_b1_rc2.tar.bz2 400fa0949aa201d993bf116461365e5d44904a3f8db6412f4f40f2b4ab490405 boost_1_61_0_b1_rc2.tar.gz d75688ecad601303dda2658e9a3d06f406dd4dc8e2c13c36bdadcac0a11dcffa boost_1_61_0_b1_rc2.zip Thanks! -- The release managers

9 15

[Root Pointer] Partial documentation
by Phil Bouchard 26 Mar '16

26 Mar '16

The documentation is not completed yet but an updated overview, a basic tutorial and the rationale are available here: https://htmlpreview.github.io/?https://raw.githubusercontent.com/philippeb8… https://htmlpreview.github.io/?https://raw.githubusercontent.com/philippeb8… https://htmlpreview.github.io/?https://raw.githubusercontent.com/philippeb8… Thanks, -Phil

1 0

[Root Pointer] Ultimate test - Neural Network
by Phil Bouchard 25 Mar '16

25 Mar '16

Hi, I wrote a small utility that reads PDFs over the Internet and converts the text into a tree of regular expressions. The goal here is to test root_ptr<> and see if it will stand up to this complexity. The code is very simple for the moment as you can see: https://github.com/philippeb8/root_ptr/blob/master/example/t100_test1.cpp Because it makes use of Bash utilities. I am also using libpstreams and "indent_facet.hpp". So anyway apparently it works fine and please let me know if you do not think the code is clean enough. Regards, -Phil

3 14

Boost libraries cannot yet be trusted
by Michael Witten 23 Mar '16

23 Mar '16

In short, I request that the maintainers start publishing cryptographically signed, strong hashes of: * downloadable files. * git objects (tags, and even commits). A cryptographic signature should probably be a personal signature of a relevant maintainer (rather than some generic project-level signature for which nobody has a sufficiently strong incentive to maintain the trustworthiness). Perhaps, each repository should include a collection of relevant public keys, so as to compound trustworthiness and ease dissemination. ------------------------------------------------------------------------ I'm new to this community, so forgive my ignorance if I've missed an existing solution. With each release, there should be included conspicuously (and widely) published means by which to check the authenticity of the relevant content. As far as I can tell, this is not yet the case. At the very least, within an email that announces a release, there should be a list of suitably safe (e.g., SHA-256) hashes for the downloadable files in question, including the hash of the relevant git commit object[s]. Now, SourceForge does indeed list SHA-1 and MD5 hashes of each file it offers for download, but they are not conspicuous; the user must know to click on an `i' symbol that sits next to each link (the `i' presumably stands for `information', but I wouldn't be surprised if it actually stood for `ignore me'). To make matters worse, that very icon and its associated functionality is only available when JavaScript is enabled, which is absurd. Furthermore, it's important that this list of hashes appear in as many independent places as possible, so that it becomes increasingly difficult to alter the association; for instance, if Gmane picks up an announcement email that includes such hashes, then an attacker will also have to compromise Gmane's servers in order to forge a new record of the intended payload. That is, widely published integrity information strongly suggests a [reasonable] means by which to calculate authenticity; certainly, the converse is true: Authenticity implies integrity. Of course, it's irritating (and unlikely) for a user to take the time to check multiple publishers for such integrity information every time a new release is made. Thus, it makes more sense to abstract away this process into a one-time dissemination of integrity information with which a user may determine the authenticity of other, related data that is provided by any publisher. Such an abstraction is provided by cryptographic signatures. By widely publishing a public key, a maintainer provides a [reasonable] means by which a user may calculate the authenticity (and thus also the integrity) of any other data that is signed by the associated private key. Now, that calculation is only as trustworthy as the private key itself, so it's important that there be a strong incentive to keep that private key trustworthy; this possibly implies that the private key in question should be intimately associated with the individual who uses it; this suggests that, as a matter of explicit policy, there should not be some generic project-level private key shared by multiple individuals across space or time. The easiest solution is to require that some *individual* maintainer of data be responsible for signing that data with his own personal signature. Of course, not every user has the machinery or desire to work with cryptographic signatures; some people are satisifed with merely checking that the hash of data matches the result provided by a trusted publisher. Fortunately, all parties can be satisfied simultaneously and cheaply: Provide the list of hashes as a cryptographically signed message. Furthermore, the source-control management tool `git' (which this project already uses) provides support for integrating cryptographic signatures; not only can a tag object be cryptographically signed, but every commit object can also be cryptographically signed. It's probably enough just to sign tags (those of releases, at the very least), but perhaps it would be worthwhile to sign a commit object that sits some sufficient number of commits ahead of the object last signed, so as to give users a kind of checkpoint of authenticity. It might be worthwhile to include in every repository the public key of each relevant maintainer (say, one file for each maintainer); this kind of publication would allow for compounding a key's trustworthiness with each new commit, and it would make dissemination of that information both easier and more specialized to its purpose. In any case, something must be done; this project sits at the core of much critical software, and its integrity should be ensured with greater zeal. Sincerely, Michael Witten

10 18

[Fit] formal review ends 20th March.
by Vicente J. Botet Escriba 23 Mar '16

23 Mar '16

Hi, There have been some that would be able to write a review next week-end. Others said that they had not enough time. Maybe having an additional week can help. I have not received confirmation from the review withards, but as there is no planned reviews for this week, I propose to continue with the review until 20th. Please take the time to do a review and share your point of view. Best, Vicente Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects. Fit is: - Modern: Fit takes advantages of modern C++11/C++14 features. It support both `constexpr` initialization and `constexpr` evaluation of functions. It takes advantage of type deduction, varidiac templates, and perfect forwarding to provide a simple and modern interface. - Relevant: Fit provides utilities for functions and does not try to implement a functional language in C++. As such, Fit solves many problems relevant to C++ programmers, including initialization of function objects and lambdas, overloading with ordering, improved return type deduction, and much more. - Lightweight: Fit builds simple lightweight abstraction on top of function objects. It does not require subscribing to an entire framework. Just use the parts you need. Fit is divided into three components: * Function Adaptors and Decorators: These enhance functions with additional capability. * Functions: These return functions that achieve a specific purpose. * Utilities: These are general utilities that are useful when defining or using functions Fit has been tested on gcc 4.6-4.9, clang 3.4-3.7, and Visual Studio 2015. For more information see: Github:https://github.com/pfultz2/Fit/tree/boost Documentation:http://pfultz2.github.io/Fit/doc/html/ We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - 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? More information about the review process can be found here:http://www.boost.org/community/reviews.html

8 16

[http] Design ideas for a request router
by Vinícius dos Santos Oliveira 23 Mar '16

23 Mar '16

Hi list, I've been designing a HTTP library for Boost inclusion for the last two years. First it was funded as a GSoC 2014 project. Then I continued to polish the implemented bits on my own and the library was peer reviewed (and rejected) last year. I'm currently addressing the requests made during last year's review and one of the requested items was a higher-level interface built on top the current building blocks that would be easier to use. One of such abstractions would be an HTTP request router. I usually do my research and check what others have done (not only in C++), read a lot of spec and do a design on my own (sometimes I ask for feedback of a few chosen ones). I rarely ask for public feedback because I usually can solve the interface issues on my own. However, Boost.Http is a new thing and I'm exploring an unexplored ground. I've been facing an issue for the last months and I'd like to have "open" feedback of anyone interested in this topic. Maybe it'll speed me up. The issue I'm facing is that (1) I haven't found enough diversity of HTTP request routers and (2) Boost.Http is a new thing and problems must be approached differently (what other HTTP library will let you do HTTP over uTP using Boost.Asio threading/async model?). Detailing the problem a little more: I categorize current HTTP request routers into two styles. The "tree style" is the style where you declare some paths to be handled and each request will be routed to at most one handler. You'll find this style usually when the author advertise a ReST support library (e.g.crow[1]). The "chained style" is the style where you declare a chain of <rule,handler> pairs (or anything in these lines) and one handler can "give up" and pass the route to the next in line. Rules in the "chained side" can overlap and an order exists (and must be explicit). You can find this style being used frequently in the Node.JS frameworks (e.g. connectjs[2]). You could reimplement these NodeJS APIs in C++ keeping a lot of the same look'n'feel. For instance, take a look at node.native[3]. I thought I could combine and allow both styles. Actually, Boost.Http don't force you to use any style and both could be used. However I wanted to implement both allowing some kind of interoperability and communication between them. There are a lot of open questions right now and I decided to implement both individually and only then come back trying to unify them. So, for now, my problem is designing the "chained style". Even implementing only "one style" I had open questions and I decided to draft an implementation to maybe give some light to my own mind. One thing that I was trying to address would be the "next" function. If you take a look at the connectjs library[2], you'll see that the "next" function is an argument passed to the handler and, if the handler wants to give up and pass the route to the next handler, it only needs to call "next". This behaviour could be emulated in C++ using std::function<>. An alternative design would be to make the handler return a bool. This is actually the design I've chose in Tufão[4] and I regret this decision to this date. The bad thing about this approach is the too-much-sync minded. If you need to communicate with a database to know whether you'll be able to handle the route then you need to block the whole thread under this approach. Knowing this is Boost and Boost is about serious C++ users I know I must be concerned about performance. Therefore, many may not like the std::function<> approach. It can imply some hidden allocation that you pay even if the handler is not going to give up on the route. Another approach would be to turn the handlers into template functors. However, this would be too much burden on the user. And if I chose this route, what would be the type of "next"? The approach I've chose was to encode the "next" function into the "request object". In Boost.Http, there is no "request object" like you'd be used to when using other APIs. Boost.Http exposes a socket and the socket will fill a message object of your choice (let's call it the input message) and later you pass it another message object to execute the reply (let's call it the output message). So the "next" function is really encoded in the input message. Other APIs use a passive style and constantly check if there is network activity and schedule new socket reads. Boost.Asio is more explicit and Boost.Http follows along. An active style is useful because it'll allow you to defer new operations to later when your server is under heavy load. Anyway, I felt that maybe I'll need a "done" function and I've added an empty one for now. I'll see if I'll really need it later when I integrate everything together. For now, just know that the "done" function does nothing. Anyway, this is my draft and I'd like to know your opinion: https://github.com/vinipsmaker/asiohttpserver/blob/router/example/router.cp… You can see that I'm declaring a static router because most of the time you don't change the rules at runtime. This router is actually more difficult to design and it'll be easier to add a "dynamic router" later on. I also want to mention that I'm aware of another effort by another developer (Uisleandro) trying to add a router to Boost.Http: https://github.com/uisleandro/Router_for_Boost.Http I also want to mention that performance of the implementation isn't really something I care about for the draft. If it were at another place it could mean that I'm not interested in implementation feedback. However it doesn't mean that I know the best way to implement these APIs and I'm still interested in implementation feedback (even more because I don't remember if I ever implemented much TMP before). Some points that I'll tackle LATER will be: - A router is a handler too, then you can have nested routers. - The router doesn't take the rule, only the handler. Later, I'll make algorithms that adapts rules and conditionally call your handler or pass the route to the next handler. This design is more flexible and I wish I could also use it in "tree style too". - How to create Message types more easily? I've read about component-based architectures before, but I never really understood them. Is there any library that was proposed to Boost in these lines that I could take a look at? [1] https://github.com/ipkn/crow [2] https://github.com/senchalabs/connect#mount-middleware [3] https://github.com/d5/node.native [4] http://vinipsmaker.github.io/tufao/ref/1.x/class_tufao_1_1_http_server_requ… -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

7 20

Sean Parent to Keynote C++Now 2016
by Jon Kalb 22 Mar '16

22 Mar '16

Boost Developers, C++Now is announcing that the keynote speaker for our tenth conference will be the keynote that started us off, Sean Parent. http://cppnow.org/2016-conference/announcements/2016/03/22/keynote-announced .html Jon

2 1

[Fit] Formal review / Kris
by Krzysztof Jusiak 22 Mar '16

22 Mar '16

Hi, Firstly, sorry for submitting my review so late. > - Whether you believe the library should be accepted into Boost Yes. Although the submission is not perfect, I prefer boolean logic, and, therefore Fit a 1 for me. > - Your name Krzysztof Jusiak > - Your knowledge of the problem domain. I have been implementing similar solutions myself when experimenting with lambdas. I have also checked out functional part of Hana library. > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design IMHO design is decent. Functionality is loosely coupled and really easy to follow. There are a few inconsistencies here and there but there were pointed out already and they don't have a huge impact on the overall solution. > * Implementation Quite a lot of macros but most of these are due to lack of language features or compilers bugs. Besides that, it looks alright. Moreover, I do agree with most issues pointed out already. > * Documentation Motivation could have been much better. Examples showing how much pain might be saved using Fit in comparison to writing the same things by hand would be great. Moreover, ready to copy examples would simplify testing the library. Personally, I would also add disassembled code for these examples showing how well-optimized code Fit can produce. Maybe, it's worth to add try-it-online functionality too? > * Tests Tests are short and easy to follow. I can't see coverage but it seems like most things are tested. Travis addition with each push make me confident that the library is always in a good shape. I would like to see performance tests though for both compilation times and run times. > * Usefulness IMHO Fit is defo a library to have in Boost for modern C++ development. I find the solutions provided by Fit very useful as I have been writing similar functionality myself. Nevertheless, documentation needs improving (as it was stated already) in order to state the purpose more clearly with clean examples. I have been worrying that there will be a clash with Hana. Having 2 modern libraries providing similar functionality would be confusing, however, my concerns were already clarified by Louis. > - Did you attempt to use the library? If so: > * Which compiler(s) Clang 3.7/3.8/HEAD, MSVC 2015 > * What was the experience? Any problems? No issues. > - How much effort did you put into your evaluation of the review? A few hours for the review, however, I have been looking and trying Fit for a while. Cheers, Kris

4 8

[test] Not using Boost.Test for an official Boost library
by Vinícius dos Santos Oliveira 22 Mar '16

22 Mar '16

Hi list, I'd like to know if it's mandatory to use Boost.Test if you intend to contribute a library to Boost. After facing an issue trying to enable compiler santizers on my tests[1] for long enough, I'd like to use a different test library. According to a survey done by Niall concerning new libs[2], everybody avoids Boost.Test, favouring assert/static_assert. I've been interested in using Catch[3], which is header-only and can be embedded, posing no problem to users (it'd be transparent). I've seen Boost.AFIO (which is not an official Boost library) already uses it. I've seen lightweight_test is also used within Boost[4]. If Boost.Test ever fix its integration problem with compiler sanitizers[1], I'd have no problem migrating everything back again to Boost.Test. However, it's more important for me to have this issue solved now so I can jump to the next task (valgrind and fuzz testing). I've also seen that some header-only libraries use a different build system for the test target[5] and using a header-only test library would be a lesser demand that should be okay. [1] https://svn.boost.org/trac/boost/ticket/11425 [2] https://raw.githubusercontent.com/boostcon/cppnow_presentations_2015/master… [3] https://github.com/philsquared/Catch [4] http://www.boost.org/doc/libs/1_60_0/libs/core/doc/html/core/lightweight_te… [5] https://github.com/boostorg/hana/blob/63c5f87dfdadd07e496cefefc63c3ea9968d3… -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

6 5

Boost 1.61.0 Beta 1 Release Candidate 1
by Vladimir Prus 22 Mar '16

22 Mar '16

Release candidates for 1.61.0 beta 1 are now available: http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.zip http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.tar.gz http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.7z As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. These packages were generated by the CI system that Rene has put together, and one user-visible change is that the directory inside archive is named after git commit hash. This will be changed for the final release. Otherwise, these were smoke-tested on Windows and Linux, and should be functionally identical to usual packages. The SHA1 checksums are as follows: b8314cff39908e6d6221bdad01ce1f1468546419 boost_1_61_0_b1_rc1.zip cd916da1aa5ed812e538975171069506ecc4560c boost_1_61_0_b1_rc1.tar.bz2 ca18da298d739ef70145b29e3bd2c8d903067075 boost_1_61_0_b1_rc1.tar.gz 2fb4b8cf9112f59aa1c4b61f2ea0c66cbbe3ffd0 boost_1_61_0_b1_rc1.7z The SHA256 checksums are as follows: 3668b868d3f883327e2ff1324e09899cbb033087147d4dd268424a7729791f94 boost_1_61_0_b1_rc1.zip e07784e9770193ff1e68cfe05c6fd08ca05913afedaedf1aca33f6da30d49b17 boost_1_61_0_b1_rc1.tar.bz2 2344369b6859ed151589286d05b38764a902884c10a4dac9c67b133c6c046130 boost_1_61_0_b1_rc1.tar.gz 9ab80608c9ec70ec7afee25f2213f803ed3d15a71ade2c6ae184c48f33fd9d29 boost_1_61_0_b1_rc1.7z Thanks! -- The release managers

10 18

[Fit] formal review starts today
by Vicente J. Botet Escriba 21 Mar '16

21 Mar '16

Dear Boost community, sorry for the late anounce The formal review of Paul Fultz II's Fit library starts today, 2nd March and ends on 13th March. Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects. Fit is: - Modern: Fit takes advantages of modern C++11/C++14 features. It support both `constexpr` initialization and `constexpr` evaluation of functions. It takes advantage of type deduction, varidiac templates, and perfect forwarding to provide a simple and modern interface. - Relevant: Fit provides utilities for functions and does not try to implement a functional language in C++. As such, Fit solves many problems relevant to C++ programmers, including initialization of function objects and lambdas, overloading with ordering, improved return type deduction, and much more. - Lightweight: Fit builds simple lightweight abstraction on top of function objects. It does not require subscribing to an entire framework. Just use the parts you need. Fit is divided into three components: * Function Adaptors and Decorators: These enhance functions with additional capability. * Functions: These return functions that achieve a specific purpose. * Utilities: These are general utilities that are useful when defining or using functions Fit has been tested on gcc 4.6-4.9, clang 3.4-3.7, and Visual Studio 2015. For more information see: Github:https://github.com/pfultz2/Fit/tree/boost Documentation:http://pfultz2.github.io/Fit/doc/html/ We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - 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? More information about the review process can be found here:http://www.boost.org/community/reviews.html We await your feedback! Best regards, Vicente J. Botet Escriba

10 64

[Fit] formal review is over
by Vicente J. Botet Escriba 21 Mar '16

21 Mar '16

Hi, The review of the Fit library finished yesterday 20 March. Thanks to all the people who participated in the review, as a reviewer or commenting the threads. I hope to announce the result soon ;-) Best, Vicente P.S. Of course you/we can continue with the discussion and add issues in github that would help to improve the library. For more information see: Github:https://github.com/pfultz2/Fit/tree/boost Documentation:http://pfultz2.github.io/Fit/doc/html/

1 0

[fit] Mini Review (consider 1/2 or 1/4 weight)
by Artyom Beilis 21 Mar '16

21 Mar '16

Disclaimer: please consider my review as partial if at all because of the way I did it (see notes below) > - Whether you believe the library should be accepted into Boost No, I don't think so. I don't feel that library adds any real value to boost: being useful or in other words significantly simplifying rather straight forward tasks can't be done However I understand that there are some cases with template meta-programming that can make library useful shown there: http://article.gmane.org/gmane.comp.lib.boost.devel/265453 So I do think it another major review after significant redesign can be done. > - Your name Artyom Beilis > - Your knowledge of the problem domain. I worked a lot with lambda expressions and various callbacks also mostly in dynamic manner rather implementing functional programming. > - What is your evaluation of the library's: > * Design I did very brief analysis of design. What concerns me is wide use of static objects and declaration of "static functions". There is significant difference between static struct foo_class { void operator()() const;... } foo; and inline void foo() { } Of course two issues: 1. Inline functions are weak symbols and don't violate ODR 2. Static variables in C++ do violate ODR (btw in C they do not) so basically you COPY every instance of the functions across compilation unit. If you define some static function that does something by macro I'd rather expect to see stuff like inline void foo(...) { static foo_instance ... f = ...; f(...) } I don't know if it is implementable but it makes more scene or at least justify use of macro. On the other hand I don't see (with exception of some corner cases) why this is better than BOOST_FIT_STATIC_FUNCTION(foo) = fit:compose(bar1,bar2) // * calls bar1(bar2(...)) inline void foo(...) { bar1(bar2(...)) } or inlined auto foo = fit:compose(bar1,bar2); Is better than auto foo = [](...) { bar1(bar2(...) ) }; I understand (after getting this reply http://article.gmane.org/gmane.comp.lib.boost.devel/265453) That there are some meta-programming cases that the library is really helpful. But this isn't something I see in library documentation or it isn't the major library purpose. And for trivial cases I think direct approach is better as it is just clearer and easier to understand for an average code maintainer. > * Implementation Reviewed barely... no comment > * Documentation This is another major issue it does not clear what library does and how it is useful. This alone would make a condition on the acceptance. > * Tests Didn't reviewed > * Usefulness It is probably the major questions that the library need to ask. What is the purpose of the library and what problem it solves. I didn't find a complete answer to this question. > - Did you attempt to use the library? If so: No > - How much effort did you put into your evaluation of the review? Several hours - mostly reading docs and code. I can't say I reviewed most of the code or most of the docs. I stopped before as I couldn't find the satisfying answers regarding what library does. I understand that if somebody would submit the library regarding astrophysics or bio-modeling I'd had hard time to understand what library does. However regarding FIT I don't think it is the case. So if you (review manager/library designer) feel that I attempted to review a library in a field I don't get - feel free to ignore my review. Artyom Beilis

7 8

[release] New libraries documentation + release notes
by Daniel James 20 Mar '16

20 Mar '16

Hi, I'm starting to compile the release notes, so please add the info for your library. Easy way to do so is to click the pencil icon at the top right of the code at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_61_0.q… Or you can just email me if you don't like quickbook. Also, the documentation for the new libraries in this release is now building okay and I've added links to the release notes, so please can the relevant people take a look: http://www.boost.org/users/history/version_1_61_0.html thanks, Daniel

3 4

[1.61] Two weeks remaining for new libraries and breaking changes
by Vladimir Prus 19 Mar '16

19 Mar '16

I wanted to remind that the master branch is closing for new libraries and breaking changes on Feb 24, about two weeks from now. We'll be closed for major changes on March 2. That's not a lot of time, please make sure any big work is completed. Thanks, -- Vladimir Prus http://vladimirprus.com

10 38

[Spirit X3] move_to
by Mikhail Strelnikov 18 Mar '16

18 Mar '16

Hi, I'm using Boost 1.60 with Spirit X3 from develop branch (because it has this fix <http://boost.2283326.n4.nabble.com/Single-element-attributes-in-X3-quot-sti…> ). If I change the rule from this: auto a2 = rule<class i2, ast::a2>{} = a1 >> a2_v2; to this: auto a2 = rule<class i2, ast::a2>{} = a1 >> '(' >> a2_v2 >> ')'; it stops compiling (both gcc and clang) with error "no matching function for call to 'move_to'". Here is full source code: #include <boost/spirit/home/x3.hpp> #include <boost/spirit/home/x3/support/ast/variant.hpp> #include <boost/fusion/include/define_struct_inline.hpp> #include <string> #include <vector> namespace ast { BOOST_FUSION_DEFINE_STRUCT_INLINE ( a1, (std::string, v) ) BOOST_FUSION_DEFINE_STRUCT_INLINE ( a2, (a1, v1) (std::vector<double>, v2) ) BOOST_FUSION_DEFINE_STRUCT_INLINE ( a3, (std::vector<a2>, v1) ) } using namespace boost::spirit::x3; auto a0 = rule<class i0, std::string>{} = lexeme[+alpha]; auto a1 = rule<class i1, ast::a1>{} = a0; auto a2_v2 = rule<class a2_v2, std::vector<double>>{} = -(double_ % ','); auto a2 = rule<class i2, ast::a2>{} = a1 >> '(' >> a2_v2 >> ')'; //auto a2 = rule<class i2, ast::a2>{} = a1 >> a2_v2; auto a3_v1 = rule<class a3_v1, std::vector<ast::a2>>{} = *(a2 >> ';'); auto a3 = rule<class i3, ast::a3>{} = a3_v1; using data = ast::a3; int main() { std::string script = ""; auto begin = script.begin(); auto end = script.end(); data v; bool ok = (boost::spirit::x3::phrase_parse(begin, end, a3, space, v) && begin == end); } Here is how it is compiled: #!/bin/bash wget --no-clobber http://netcologne.dl.sourceforge.net/project/boost/boost/1.60.0/boost_1_60_… tar -zxvf boost_1_60_0.tar.gz wget --no-clobber https://github.com/boostorg/spirit/archive/develop.zip unzip develop.zip mv ./boost_1_60_0/boost/spirit ./boost_1_60_0/boost/spirit_old g++ -std=c++14 test.cpp -I./spirit-develop/include/ -I./boost_1_60_0/ -o test

1 0

[Root Pointer] Benchmark
by Phil Bouchard 17 Mar '16

17 Mar '16

So I renamed block_ptr<> to root_ptr<> and the code is accessible from here: https://github.com/philippeb8/root_ptr I am sorry but I made a mistake in the benchmark again. root_ptr<> wasn't using the fast allocator. Now it does and the new benchmark is: unique_ptr (new): 42.3736 unique_ptr (make_unique): 59.6104 shared_ptr (new): 69.9175 shared_ptr (make_shared): 46.9994 shared_ptr (allocate_shared_noinit): 31.0648 root_ptr (new): 30.5549 Regards, -Phil

5 36