March 2016 - Boost - lists.boost.org

[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

[ann][offtopic] GSoC with the STE||AR-Group
by Thomas Heller 17 Mar '16

17 Mar '16

Hi list, We are very sad that Boost didn't make it into GSoC this year. However, for students with enthusiasm for C++, Parallelism and Concurrency and looking for an interesting project for this summer, there are other opportunities. The STE||AR-Group (https://summerofcode.withgoogle.com/organizations/5183170693562368/) is looking for prospective students, we have a large variety of projects surrounding the HPX Parallel Runtime System (one of the reference implementations of the upcoming additions to the C++17 standard for parallelism and concurrency). You can find our project ideas list here: https://github.com/STEllAR-GROUP/hpx/wiki/GSoC-2016-Project-Ideas In addition, if you have a project idea you'd like to mentor that would fit into the scope of our organisation, we would be more than happy to welcome you! We are looking forward to your responses at hpx-users(a)stellar.cct.lsu.edu or on our IRC channel #ste||ar on Freenode! Best regards, Thomas -- Thomas Heller Friedrich-Alexander-Universität Erlangen-Nürnberg Department Informatik - Lehrstuhl Rechnerarchitektur Martensstr. 3 91058 Erlangen Tel.: 09131/85-27018 Fax: 09131/85-27912 Email: thomas.heller(a)cs.fau.de

1 0

[Fit] About supported C++ version
by Vicente J. Botet Escriba 16 Mar '16

16 Mar '16

Hi, I was wondering if Boost.Fit shouldn't be a library as Boost.Hana, a library that makes use of the last C++ version and avoids as much portability issues as possible. Which C++14 features will make the library simpler? Which adopted C++17 features will make the library simpler? Which other C++ features would be missing? Paul I guess that you are using a C++11 compiler and want to support this version, could you confirm? Best, Vicente

2 3

Providing means to verify integrity and authenticity for releases
by Daniel Hofmann 16 Mar '16

16 Mar '16

The current download page at > http://www.boost.org/users/download/ redirects the user to SourceForge for downloading sources and / or binary Boost distributions. SourceForge can no longer be trusted as a hosting platform, as you can for example see following this thread > http://lists.boost.org/boost-users/2016/02/85662.php where a user was tricked into downloading some arbitrary binary while downloading a Boost release. Unfortunately there does not seem to be a secure and convenient way to download Boost releases. Although Github's Boost "releases" can be found at > https://github.com/boostorg/boost/releases but those are only repository snapshots, from which you can not even build a Boost distribution. And whereas the Boost 1.60 rc1 announcement mail at least provides checksums > http://lists.boost.org/boost-users/2015/12/85435.php The official 1.60 release announcement mail does not > http://lists.boost.org/boost-users/2015/12/85467.php Correct me if I'm wrong, but there is no way for obtaining a Boost release and verifying its integrity and authenticity. The only option I'm seeing is recursively cloning all Boost repositories from Github and building a release by myself. Can we please change this situation? Here are some options that come to mind ordered by amount of effort: - Providing checksums - Educating users on the Downloads page - Signing releases with a trusted Release Team key - Changing the hosting platform Cheers, Daniel J H

7 8

[ann] C++ Archive Network
by Egor Pugin 16 Mar '16

16 Mar '16

Hi, I'd like to present my project - C++ Archive Network (or simply CPPAN). You can consider it as (yet another) C/C++ package manager. In the beginning it was targeting C++ Modules, but it seems it can handle many current C/C++ projects. You can read more information about idea and motivation from links below (see docs). This is an alpha release (0.1.2). I'm announcing it only here to get initial feedback (but still boost community is large enough). As always the general idea is to create programs faster, to reuse and share your or anyone's code. But specifically here: source only packages (no tools, no tests in distribution pkg - keep all your stuff in your repos), Modules-like paths (org.boost.algorithm), semantic versioning (semver.org) zero-conf. projects, all-or-nothing dependencies (no optional deps.) and some other convenient features. At the moment CPPAN works only with CMake. It generates files that you include to your project (see docs). To be closer to boost and modern C++ community I added some popular projects as demo versions: - boost 1.60.0 - all projects - some core parts work (filesystem, thread, log, asio etc.), did not tried less used libraries. - new boost libs: coroutine2 (added but not set up, so does not works), dll - boost incubator libs: fit, DI - you can try them faster during reviews - gsl, range-v3, mach7, sqlpp11 (and connectors) - some modern libs - concepts libs: cmcstl2, text_view - so users can try and adopt new C++ features faster - google's: gtest,gmock,protobuf, recent 'highwayhash' lib - sqlite3 (3.11.0) - zlib, bzip2 - libressl - image libs: libpng, tiff, gif, webp, some others - libpqxx Most of them just works. Almost all dependencies are met. In boost.* I do not untangle the core dependencies, so base dependency-ball is quite big. I believe that library authors can eliminate unneeded deps better. Links: https://cppan.org/ - website https://github.com/cppan/cppan - client, use issues for feedback https://github.com/cppan/cppan/wiki - docs https://github.com/cppan/demo_project - example project that uses cppan https://github.com/cppan/packages - example packages (config files) https://github.com/cppan/packages/blob/master/boost/boost.cppan - base boost config file (big list of deps, probably can be shorter) --- ps. I'm not writing about pros. and cons. Both are present. Just give CPPAN a try and we'll see how we can improve it. -- Egor Pugin

5 5

Re: [boost] [Block Pointer] Benchmarks
by Glen Fernandes 15 Mar '16

15 Mar '16

On Sun, Mar 13, 2016 at 1:02 PM, Phil Bouchard wrote: > Thanks for your help. > > So block_ptr<> wouldn't be a drop-in replacement for shared_ptr<> but an > add-on for: > - complex containers, > - neural networks, > - C# / Java / Javascript engines, > - etc. > No problem. Also renaming the thread to reflect the current benchmarks (since it doesn't appear that block_ptr is faster than shared_ptr where creation is involved). 1. Gathering these benchmarks is always useful, even if block_ptr was not designed to be a drop-in replacement for share_ptr. So you had the right idea, even if the execution needed some work. It's important to get the execution correct, though, otherwise the results are not meaningful - which is where I (and I believe Rob, also) was trying to steer you. 2. Looking at the numbers you obtained after modifying my benchmark example, they are close enough that at least you could say "Using block_ptr over shared_ptr won't be a significant performance loss": > unique_ptr (new): 47.7686 > unique_ptr (make_unique): 46.8545 > shared_ptr (new): 77.8261 > shared_ptr (make_shared): 50.8072 > shared_ptr (allocate_shared_noinit): 33.021 > block_ptr (new): 69.6554 3. There are more benchmarks beyond just creation (though creation is likely the most meaningfully expensive one). Copying overhead might be one: I haven't looked at what is involved in copying a block_ptr, but some work happens when you copy a shared_ptr. 4. shared_ptr by way of allocate_shared allows creation to not involve 'new' expressions, or even a call to '::operator new(std::size_t)' at all. i.e. For those C++ projects that have a requirement for all dynamic allocation in their project to involve some stateful custom allocator instances of some stateful custom allocator type, they can still use shared_ptr (with allocate_shared). Is this possible with block_ptr? I hope to take a look at the block_ptr motivation, design, and implementation when I have some time next week. The title of the thread caught my attention; "X is 600% faster than Y" always has a high excitement potential. Glen

8 16

[Block Pointer] Update
by Phil Bouchard 14 Mar '16

14 Mar '16

Hi, - So I've restructured all the code in the correct namespaces boost::smart_ptr & boost::smart_ptr::detail: https://github.com/philippeb8/block_ptr/tree/master/include/boost/smart_ptr - I am now using another smart pointer to refer to proxies because it is safer but the code is 15% slower than without it (now ~= shared_ptr<>): make: auto_ptr: 26211292 ns shared_ptr: 27291607 ns block_ptr: 61097868 ns new: auto_ptr: 23240569 ns shared_ptr: 48016207 ns block_ptr: 55554121 ns - Because of the removal of the proxy optimization there is a new caveat; if you assign an rvalue (temporary pointer on the stack) to a pointer on the heap (opposite of normal heap object assigned to stack pointer) then there the behavior will be undefined. I am looking to fix it or throw an exception but for now it's better not to use rvalues when assigning to pointer living on the heap as such: https://github.com/philippeb8/block_ptr/blob/master/example/t100_test1.cpp#… Regards, -Phil

2 13

[Fit] formal review ends today, 13th March.
by Vicente J. Botet Escriba 14 Mar '16

14 Mar '16

Hi, The formal review of Paul Fultz II's Fit library ends today, 13th March. If you had not time to do the review and you plan to do it, please let us know so that we see if the review can be extended. Up to now we had 3 formal review (2 for conditional acceptance and 1 against, not now). I have not done a review myself, but I have created a lot of issues on Github. Best regards, 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 We await your feedback!

4 6

[Fit] Review
by Zach Laine 13 Mar '16

13 Mar '16

- Whether you believe the library should be accepted into Boost Yes, conditionally. * Conditions for acceptance I think the documentation and naming issues I raise below, and those filed on GitHub by me and others should be addressed before acceptance. Also, the ADL issues that Steven Watanabe alluded to previously need to be fixed. After that, I think it should be re-submitted. - Your name Zach Laine - Your knowledge of the problem domain. I do generic programming regularly, and have done for years. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design I think it's good. I particularly like the fact that it attempts to keep everything constexpr- and SFINAE-friendly wherever possible. I *really* like reveal() and failure(). Too few TMP-heavy libraries pay attention to providing good error messages. I have no problem with the constness requirements on Callables used throughout Fit, as was discussed previously. I even consider this a feature, allowing me to detect non-const Callables, which are almost always an error on my part. This is especially true since std::ref() and mutable_() let me explicitly choose how to handle mutable Callables, in a way that is also explicit at the call site. There are a number of adaptors that I find have obscure names: by() is a projection; why not call it project()? compress() is defined in terms of "fold", with a link to the Wikipedia page for same; why not call it foldl()? Similarly, reverse_compress() should be foldr(). flow() is a super obscure name! Why is this not reverse_compose() or similar? indirect() could more easily be understood if it were called deref() or dereference(). I don't feel as strongly about partial(), but I think it might be clearer if it were called partial_apply() or curry(). conditional() should be called invoke_first(), call_first_of(), or similar. I find it too easy to confuse with if_(). * Implementation I only briefly looked at the implementation, and only a few adaptors at that. What I saw did not leave me any concerns in particular. However, I *am* concerned by Steven Watanabe's claim that the library is ADL-unsafe. He did not state exactly why that I could tell, but this needs to be addressed if so. * Documentation The Quick Start section is good at showing a compelling motivating case for using the library. The result at the end of the section looks like a very good start on a "Scrap Your Boilerplate" solution for simple, dump-style printing. It's relatively easy to read and write. The documentation is what needs the most work, from what I've seen. The Quick Start is quite nice, but then there are some things that are underexplained in the subsequent Overview and Basic Concepts sections. For instance, why are these macros used everywhere and what do they do? They should be used for the first time after showing what the expanded code looks like. This will justify their use for those users that want them, and show those that don't what they can write instead. Others have written during the review that they don't understand why this library is useful. I think this is simply a documentation failure. I find the printing example from the Quick Start compelling, but perhaps Paul could show how it would have to be done if hand-written (even if only partially). Also, Paul has told me offline that there are a small number of primitive operations on which everything else is built (pack, unpack, and apply, IIRC). Perhaps show how those can be used to implement the other adapters, and how hard they are to write yourself. Showing how at least some of the library can be used as fundamental building blocks would go a long way. Some specifics. I have read the online docs before, and I put several bugs into the GitHub page for what I consider insufficient examples or explanations. Some new points, though: I think alias() is in bad need of a motivating example. I don't understand the distinction between lazy() and protect() just from the descriptions. In particular, this is what protect()'s docs say: '' The protect function adaptor can be used to make a bind expression be treated as a normal function instead. Both bind and lazy eargerly evaluates nested bind expressions. The protect adaptor masks the type so bind or lazy no longer recognizes the function as bind expression and evaluates it. '' I don't know what "masks the type" means here. This really needs an example. * Tests I did not run the tests, and just sort of spot-checked them. They seem a bit thin. In particular, one of the ones I looked at was conditional(). This one seems like it is needs more coverage, including thorny ones that must be kept working when maintenance occurs. There are probably others adapters that need similar treatment. Also, consider this -- Steven pointed out this as a failure case: boost::fit::conditional(identity(), identity())(0); and Paul says that it is supposed to fail, and that this failure is a feature, not a bug. If so, a minimal use like this that fails to compile needs to be added as a fail-compile test (and of course this intention should be documented). * Usefulness I think the library is very useful. There seem to be some things in there that use of which might be deemed a bit clever (not the good kind), like infix(), but then there are things like conditional() that I can see being *extremely* useful. - Did you attempt to use the library? If so: Yes. * Which compiler(s) Clang 3.6 * What was the experience? Any problems? I found I could gin up quick uses of things like conditional() (the most interesting adaptor for my purposes) in a short period of time. It was quite straightforward. - How much effort did you put into your evaluation of the review? About 5 or 6 hours. Zach

9 23

Alternative names to Boost.Fit
by paul Fultz 13 Mar '16

13 Mar '16

Hello All, Boost.Fit is a function utility library, however, the name currently doesn't have anything with this. I originally chose the name because it started with F(for function) and it was short and sounded nice. However, there could be some names(or abbreviations) that more adequately describe the library. Here are some alternatives that are short: - Boost.FP - Boost.FPL - Boost.Fun - Boost.FN Of course, I prefer the Boost.FN name. Names like Boost.FP or Boost.FPL could imply that it provides full functional constructs whereas Boost.Fit does not and is mainly focused on functions. Either way, this is something reviewers could consider as they review the library as I am not strongly tied to the name Boost.Fit. Thanks, Paul

13 27