March 2016 - Boost - lists.preview.boost.org

[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